Effective Programming

where agility meets computer science

Apr 27, 2020 - LB

Team First, Product Second

What if product development was just a side-effect of a good team?

What if product development were more broadly considered a forcing function for team building?

I propose that if projects focused their energy on building and cultivating good teams, then good product development would naturally come about as a by-product. The suggestion here is that a primary focus on product development is less beneficial than a primary focus on team development. It plays off the idea that identifying and then focusing on any metric directly has less real benefit then understanding and focusing on the things that work together that lead to the thing that is being measured.

For instance, if something was broken and needed to be fixed, what if the measure for success was not who fixed it or even what the fix was but rather, how said fix was applied. How involved the team was. How aware everyone on the team was of the issue. What steps were taken afterwards to share with and improve the team’s understanding and ability to respond in the future.

To bump this up to the business level, what if the stated goal of technical and team leads was not necessarily to deliver projects on time but instead, was very explicitly to develop teams? And what if this posture was realized in terms of promotions, acknowledgement, appreciation, and event published tradeoff sliders?

An interesting inference - if this hypothesis does not hold true on your specific project, then your project may be depending on individual productivity more then it should. And that isn’t necessarily the end of the world. It is perfectly reasonable for a product over team model to work, albeit not ideal, I’d wager it is largely how we got here today.

Keep in mind - this is just a hypothesis. I’m curious what just such an experiment would uncover …

What do you think? Give me some feedback if you have a chance!