I picked up my Xbox One this morning – a special white console with “I made this!” engraved on it. The reviews started appearing last night, and for the post part, they’re quite positive (and I’m not surprised by the drawbacks listed in the reviews I’ve read so far). Now that this project is officially behind me – and before I figure out what’s next, I have some backlog blog posts to share.<\/p>\n
I gave a keynote at STAR West in October on “Lessons learned from Xbox One”. Given that it was an unreleased product at the time at the time of the presentation, rather than talk about the details, I spoke mostly about the team, and how strong team principles lead to great software projects (I spoke of my love of the Xbox team in a previous post – http:\/\/angryweasel.com\/blog\/?p=723)<\/a>. I thought I’d share a few of those lessons.<\/p>\n In order to build great software, build a great team first. I’ll say that differently in case it didn’t sink in (or make sense). Worry about building a great team first, and then let them build a great product. I realize this isn’t always an option for every organization, but I see too many teams take an existing group of people, and then try to make a product that isn’t in the sweet spot of that organizations strengths. A good team can usually make a few good things, but a great team can make anything great.<\/p>\n That leads to a phrase I heard once that rings too true – “Don’t ship your org chart”. Just over ten years ago, I was working on Windows CE (an embedded operating system loosely based on Windows). During product planning, I noticed what looked like an unbalanced number of networking features (there were a lot – including some relatively obscure functionality). I didn’t know if it was a product strategy decision, customer requests, or what, so I asked. The answer was, “Our networking team has a lot of people, and we need to keep them busy.\u201d To this day, I still don\u2019t know why there was no attempt to shift people around as needed for features customers<\/em> wanted, but I do know it seemed silly at the time, and it seems silly now.<\/p>\n Which leads to\u2026<\/p>\n I\u2019m a believer in teams filled with (or at least largely populated by) specializing generalists<\/em>. Everyone certainly doesn\u2019t have to be able to do everything<\/span>, but every team member should be able to do many things well, and a few things very well. It\u2019s important, when building a team to have diversity in both generalization and specialization \u2013 and match those skills with what\u2019s needed for your project.<\/p>\nLesson 1: Build a Great Team<\/h4>\n
Lesson 2: Diversity and strengths<\/h4>\n