Swizec's articles in the "teams" category
I aim to write mindblowing emails with real insight into the career and skills of a modern software engineer. "Raw and honest from the heart!" as one reader described them.
Below are 19 articles filed under teams
. Enjoy โค๏ธ
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. ๐"
The swarm doc
Here's a doc I like to use to structure the pre-work design chat that makes later code review a breeze.
Coordinating at the end is too late
When working: sync first *then* async
Approve with comment
A shift in your code review process can boost your team's productivity. Empower authors to make the call.
The answer to 5 soloists in a trench coat
Team dysfunction where everyone's a soloist? Try this fix: Force the team to work on ONE story at a time.
Why you need a regular retro
Agile is something you are, not something you do.
5 tips for effective standups
Talk about today, not yesterday
Be action oriented
Unearth the surprising connection between the CIA's Simple Sabotage Manual and your productivity, and learn how to transform tiny actions into big wins. Dive into Swizec's engaging exploration of how small actions can make a huge impact on your progress.
Let juniors speak first
Want an engaged engineering team? Let juniors speak first.
What I learned from Team Topologies
You can't escape Conway's Law. Might as well use it for good.
Working with product
A strong partnership with product is key to an enjoyable engineering life
Squash merge? Really!?
Learn why squash merging is your friend - from hating it to loving it! Squash merging helps you keep moving and focus on the work instead of recording the work.
Why trunk-based development is best
Merging finished work straight to main and deploying to production right away, scales to teams of thousands. This approach is counterintuitive to many engineers who may be used to working on their own
Scaling teams is a technical challenge
A founder friend asked me about growing pains on his team. How do you avoid stepping on each other's toes?
The art of the cowboy merge ๐ค
how do you catch a critical deadline that cannot be missed? We're talking external stakeholders, millions on the line, and it all hinges on *your* team getting it done on time. No overtime
Reader Question: What do collaborative teams look like?
New members on our team invariably say 2 things: 1. Wow I've never seen a team move this fast 2. This approach feels weird. I'm uncomfortable Teams like this are not common.
Reader question: So about that perfect burndown chart ...
If your approach works so well, why isn't every team doing this?
How we made the best burndown chart you've ever seen
My entire career I've never seen a sprint finished on time. The new manager said "Oh I think we can fix that" ... 18 months later he proved me wrong
What's more productive, a team or a talented soloist?
Engineers *hate it* when you say it doesn't matter how good they are because a team will outcode them any day. But it's true, you can't build something big on your own.
WorkInProgress kills your progress
If it takes 6 engineers 10 days to complete 6 projects in parallel, why does it take 8 days when you work together ๐คจ
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. ๐"