Team Projects (2009): Leadership, Product Management, Test-Driven Development
Do you prefer to work alone or work in a group? Your answer is closely related to what defines an introvert and an extrovert, although I’ve certainly known extroverts, who’d rather avoid group projects. Why is that? Why would an individual who typically draws energy from other people like an extrovert want to avoid them when tackling a project?
The reason is: Team projects are hard. Who’s reliable? Who’s going to lead? Is he or she a team player? These are just a few of the many questions that can make your life stressful for months as you journey through unknown territory with people you don’t know or people you don’t know as well as you thought.

Different projects require different strategies. I tend to play the utility role, although my preference is to lead the project. I try to find the gap in skills and experience amongst the team members and fill that role. What follows are strategies for adding value to a project team with a focus on leading groups when applicable.
Here are some tips for common scenarios that can help you get started successfully on a project team.
- If the team needs quality research, put in the time and effort to find the information needed.
- If the groups lack organization, create the project plan and make assignments.
- If there’s no direction, take the reins and lead the group.
My general preference initially is to see who’s going to fill which role or get organized right away and start leading the group. That generally depends on whether there’s someone else in the group willing and capable of leading it. If they’re willing, but not capable, you can try to force the situation. I find it much more effective to let them try leading if you have enough time to experience some failure as a team. Folks who aren’t capable due to their lack of knowledge, character, or work ethic may seem competent to a team initially. They’re usually rightfully seen as poor leaders within a few meetings. At that point, step up and create some momentum.

Here’s one example of the evolution of a project and what can be gained by leading and taking on multiple roles.
On Project CT there was little time pressure, liberal freedom to choose the technology I wanted, and only moderate management oversight. The end result was a tool that mirrored end users desired behavior despite an initial requirement that was beyond vague. By taking on the challenge of building a solution to a problem with unclear requirements on a brand new team, I was able to lead the project from beginning to end, educating new Developers and a PA on the project and assigning responsibilities as needed. In addition, I picked up some new skills that helped me significantly in the future: Test Driven Development (TDD) and basic Product Management.
I was given this project when I first started on this team, which was using primarily VB 6 to build its tools. The team needed to update its outdated technology stack, so we chose .NET with C# for Project CT. I prototyped several versions of the tool and reviewed them with our internal customers at least bi-weekly, which started my Product Management growth.
The meetings allowed me to quickly hone in on what was important to the users. This process quickly taught me the importance of frequent communication, negotiation, and prioritization with your end users. When they saw that I was trying to deliver the maximum value to them, I earned their trust and they helped me make tough tradeoffs in what features to include in the tool. I think it can be effective for people to step outside their comfort-zone to pickup work in another area if only to spend some time thinking from that different perspective. Often that experience gives you just enough insight to make decisions on your own when you’d normally need someone else’s input in the future.
Completing the project took some time as I was growing my knowledge of Test-Driven Development (TDD) by practicing it strictly on this project. The TDD learning curve was challenging and time-consuming, but ultimately worthwhile as the quality and maintainability of the software increased. Plus, I had a new tool in my toolbox. From this experience I learned that changing your primary development methodology is painful, but can produce great rewards and allow you to see your work from other angles.

My biggest learning from this project was the speed of communication you can effect by taking on multiple roles on a project. At times I acted as a Developer, Architect, Project Manager, Analyst, and Product Manager. Most projects are bigger, and so people are naturally more isolated in a single role. Working on small projects can be liberating in that it feels as if you can get much more done quickly with less effort. This must be the allure of start-ups.
Key Concepts
- Team projects are hard. To be successful, focus on where you can add the most value whether as a utility player or a leader.
- Different teams require different strategies both collectively for the group and for you as an individual.
- Folks that want to lead, but aren’t capable, will usually force their way out of the leadership position. Be prepared to step in when needed if that’s your desire.
- Challenging assignments bring the significant benefits and career development growth through gaining new experience and skills. If you take on a leadership role, you’ll often have the opportunity to step outside your comfort zone in an area you want to grow.
- A key to Product Management is communicating frequently with your customers. You need to do this to understand their job. Your job is to make them more efficient and more effective at their job.
- Changing development methodologies can be painful. I encourage developers to be open-minded and try it. You’ll always have your old skills available, but building new skills can dramatically increase your effectiveness.
- Small teams are more efficient due to their speed of communication and decision-making.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader.
– John Quincy Adams
(Note – My favorite Toastmaster President gave me a mug with this quote inscribed on it at the end of my year on the Siemens Toastmasters Board in 2011. It’s one of my favorite presents, since it reminds me of my potential and what I love in the people who’ve inspired me.)