Building a Team — Hints for Project Managers and Product Owners
This article was written by TEONITE’s COO — Michał Gryczka.
In this series of articles I would like to share practical aspects of development process in context Team as a Service (TaaS) model, drawn from our team’s experience in delivering commercial projects. In particular you will find out about:
- ‘selecting’ team members with adequate skills and experience
- bootstrapping development process using Agile principles
- communication with project stakeholders (POs / PMs / CTO etc.)
- understanding business and technological objectives (CPO / CTO)
- handling inter-team relations dynamics (external vs internal)
We would like to tell you these stories through the lens of a few challenging projects delivered by our brave team in the ‘Team as a Service’ model.
Please keep in mind that this is just an example, Team as a Service solution should offer full flexibility when sourcing IT staff, which means that you can assign more people to your projects when you need it, or reduce the number when the workload is smaller.
Now, without further ado, let’s get into the subject of TaaS in practice. As this is a complex issue I will divide it into a few blog posts. Today we’ll focus on how to select the right employees for any given project.
CHOOSING TEAM MEMBERS FOR THE PROJECT
Here are the most crucial criteria to be taken into consideration when choosing team members for a specific project:
- Technical skills in programming / design / architecture
- Experience in teamwork
- Willingness to solve problems
- Engagement
- Ability to clearly communicate both problems and solutions
These criteria are not in any particular order, as we observed that all of those contribute equally to a successful delivery of the project.
The most important for you to know is how to verify/validate the level of particular skills among your team members. Remember though, that our goal is to build a team, so it is not necessary that all team members need to have equal level of all skills mentioned above. The more important thing is that they complement each other because this allows them to properly use those skills and create synergy, yielding better results in the end.
During a job interview it is extremely difficult to be able to verify all those elements, that’s why it is essential to assign some time for internal projects and side tasks which will give you a perfect opportunity to check whether the team member will be able to cooperate/perform on a desired level. It’s important to have a controlled environment, where you can focus on validating and observing, because in a real world project there is too much pressure and never enough time to do so.
I can share our experience on how we organize our internal projects. During those, we tend to focus on observing and coaching people, rather than on business perspective. Assigning internally the roles of Product Owner and Scrum Master to senior team members allows us to control each aspect of the process and draw insights about what our adepts should improve. What is also important, is the fact that we strive to make those internal projects more than exercise. We make sure that they have their purpose and usability in the future.
All of the above is not just theory, since all of our insights are based on dozens of customers and delivered projects. We have decided to contribute more than just with Open Source solutions and that’s why I’m sharing a bit of our know-how.
THE PROJECT
Our client was one of the most innovative suppliers of construction and engineering support solutions worldwide. They needed a trusted partner to support them in the process of advancement of their signature product.
CTO of the organization was looking for an efficient way to increase the development speed without compromising its quality, and after discussing the requirements we were able to start composing a dedicated team. Our objective while choosing the team members was to maximize synergy and versatility, at the same time minimizing the single point of failure. We have started the cooperation with a team of three, then ended up scaling up to six people in the assigned team:
- Two senior full stack developers
- Two full stack developers
- One quality assurance specialist
- One scrum master
Thanks to a diversified team composition, we were able to function swiftly even during possible edge case scenarios.
I hope that you find the shared insights helpful and you will be able to implement some of the aspects to your organization. Being able to choose the right team members for a project is just a part of a bigger picture of oversight and team building efforts — after all, your team is your competitive advantage.
You can invest the time to build the team, but keep in mind that there are alternative solutions which can achieve the same goal without you having to invest too much or take any unnecessary risks. If you are not sure what would be the best solution for you — hit me up on Twitter or Linkedin.
If you’d like to read our previous blog post, where we describe different cooperation models, you can find it here.
Also, be on the lookout for the next blog post regarding bootstrapping a development process.
