What I Learned From My Last Team

I started on a new team this past week — I’m super excited because it’s a 12-week project in Swift.  My last two teams were Ruby on Rails teams, and all the teams before that were Objective C.  Usually, when I’ve moved between teams, I’ve always felt wayyyyy behind and overwhelmed at life.  I thought that I would feel this way because it’s a Swift project, and I hadn’t done Swift full time.  However, I’ve quickly come to realize how much of a strong iOS foundation I had.  I’ve always felt like I was the least knowledgeable person on every team that I’ve been on (whether or not that’s true), but I didn’t feel that this time.  It was such a cool feeling!

After being in a week or so of meetings on the new team, I’ve recognized a lot of the things that I’ve learned from my last team.

1. Don’t give up so fast.  Usually, I defer to people who have stronger opinions.  On my last team, a *lot* of people had strong opinions, and I kept getting feedback that I needed to voice my opinions more and fight for them longer instead of deferring to the loudest person.  Today, I was in a meeting, and I felt strongly about something, and I stuck with it for a while.  Past Neem would have given in much earlier, but my experiences on my old team allowed me to learn how to stick with my opinion and persuade people to come to accept something closer to it.  I didn’t win all the “battles” but I trusted my gut a lot more.  During the meeting, I definitely came to realize that I learned that skill from being on my old team.

2. Stories should be small and have super clear acceptance criteria.  I’ve been on a super small team of 4 developers before, and the team lacked a lot of formal process of writing stories.  I hated story writing at the time, and I wrote terrible stories with terrible acceptance criteria.  I didn’t know that at the time, and the QA at the time just had to wing it and understand what our weird words meant.  On my last team, the process was pretty freaking solid.  If a story was poorly worded, the devs would complain and the QA would beautifully misinterpret it in frustrating, magical ways.  We wrote stories as a team, so it became every developers responsibility to make sure that the stories made sense and covered the entire scope of the feature.  I felt like my old team really solidified my skills in breaking down a large feature, estimating, and finding the edge cases that needed to be stories.

3. Meetings shouldn’t last longer than an hour, and if they do, add in a break after the hour mark.  I didn’t realize that the reason I hated meetings so much was that my brain got kinda mushy and bored and distracted and whatever, and I really just needed a break.  Sure, people think it’s insane that I need to check my phone for texts and Facebook notifications, but my brain just really needs a breath of fresh information that’s not purely informational for business purposes.  I can get away with a break if I’m chatting with other humans, but my brain seems to just turn off after monotonous emotions of meetings.  I also found out that I get super effing hangry if we do lunch meetings!  I nixed that immediately on my new team.

4. There’s a million ways to do one thing, but team consistency is key.  A couple teams ago, I was in a codebase that had probably half a dozen ways to do notifications to other classes within the app.  It was a nightmare when trying to add anything new because you had to learn these different ways of doing things and when you did one thing one way or another thing another way.  I really liked that my old team tried to stay consistent with the existing patterns, and really understand *why* we would change to a new pattern.  When we did change to new patterns, everyone on the team would get some kind of prompt to go look at the code and make sure that they understood how and why the thing changed.  Pair programming is nice in that you get more eyes on the code, but I appreciated that extra level of making sure everyone was on the same page instead of just relying on exposure to the code to take place of knowledge sharing.

5. Team turnarounds are awesome!  I’ve been telling my new team that I’m turnaround happy.  I recognize that some people hate it when they have to context switch to an impromptu team meeting.  I also recognize that it’s sometimes easier for people to just ask for a turnaround instead of struggle with something for a long time.  Overall though, I really appreciate a team that is super receptive to stopping what they’re doing, turning around, and listening.  I thought our team worked really well together because we were constantly exposed to others struggles and could bounce ideas off each other really easily.


I’m sure there are a ton of other things that I learned on my last team (like mad Ruby skills), but these are the things that I felt like my old team really helped me grow as a developer.  Hopefully, in twelve weeks, I’ll have another post on the things that I learned on my current team.

Leave a Reply