Thanks for putting so much thought into your writing, Joel. I especially liked where you talk about design as a team sport—welcoming old ideas, embracing the work from your partners (I want to steal your PM's idea of the timeline.) And I loved your reference to Carl Sagan.

Don't stop writing.

Loved this one like the earlier ones too. There's a lack of content around team dynamics, getting buy-in, and driving change as a team (not as an individual). This one really hit home.

Great write-up Joel!

I recently joined a company that practices Scrum and agile development, and it has changed how I look at software design/development. I almost exclusively work on features in parallel with our developers, and they all go live. We work in tiny increments, which means we will release each of those increments and see what happens. Did it have the effect we'd hoped? If not, we evaluate why and either kill the feature or make it better. If yes, we keep improving on this feature until it is no longer worth the effort. This means that we never have months of work that goes untested on the assumption that it will solve the problem we have.

I'm thinking about writing a piece on working in a cross-functional agile team as a designer, I think a lot of us are still struggling with the waterfall methods that burden our industry.

This is a great read, thank you for this perspective!

Would love a bit more info about how you document everything on Github. I would love to go back into a timeline of an idea and how it was discussed etc.

This is a great conversation, and I think I'll write about it some day, maybe in my newsletter.

I think too often we conflate the final outcome (the thing we shipped) with our competency as designers, but that's inherently tricky. You're never designing in a perfect world, so you almost never ship the perfect thing. Usually there are compromises due to technical hurdles, new information from research, lack of resources, politics, etc.

The nice thing is that every company has these issues, so as long as you frame and communicate them properly, they'll understand, and maybe even be impressed with how you dealt with certain issues. For instance, pivoting and shipping Team Accounts v1, a mediocre product at best, which was just the best thing I could ship at the team, is the thing that impressed GitHub the most during my interview.

It feels better when something we've made is actually out there, especially when it's close to the form you wanted it to take, as if that validates the work we put in. But we're only human and all we can do is our best within a set of circumstances. So the advice I'd give is make the portfolio about the process. Be candid about the issues, and show me how you dealt with them. Because if I hire you, there are going to be issues you'll have to deal with too. I want people who make the best of whichever situation they're dropped in. Showing evidence of that can be way more powerful than just showing me that dope thing you shipped.