Table of contents
The team
When framed from an end-to-end perspective, Data Science projects usually involve a large variety of roles: data scientists, machine learning engineers, business analysts, product managers, software engineers, designers, etc. We can still consider it a Data Science project if the data part is the main lever for the business outcome and where most of the risk lies. The same principles will apply even if the other parts are equally important.
Define the working team as soon as possible
Working end-to-end makes it hard to put together everyone needed to ship it. We know the different functions will have different workloads and execute at intermittent moments, but defining a working team does not mean they will be working full-time on that project until completion.
You will need to get to other managers to request people for it. The RFC is a great tool to communicate the need and project purpose.
Until a particular role does not gets involved, we can consider them as a point of contact who will follow the project and communicate to their functional area, e.g., a designer that keeps the designing team aware of that demand. It is valuable because they can contribute to design choices and feel like project owners, which is undermined when there is a simple handover from one role to the other.
To build the intelligent coupon-referral program, we need to integrate the model decision into the mobile application, display the coupon, and nudge selected customers. So we will want to involve designers and mobile engineers from the beginning. If, at some point, we discover we need more additional roles, integrate them. A Product person from a referral or growth team was probably involved in the discovery and can lead or follow the project.
The different roles
Developers
For Developers, people who will design, break and execute, it is important to know their seniority and set expectations regarding their role in that project. Be mindful of general expectations about their seniority. For example, Junior members are usually not required to translate an abstract business objective into a solution from their domain. So if the project requires it, make sure someone can do it for them.
As a project leader, you are accountable for a division of work that respects the expectations for every level but challenges them to grow. Setting the expectation and letting them do it usually works. Act on explicitly allocating tasks only if needed.
Interns and Junior
People at this stage have a significant learning component in most things they do. We need to account for that. In a perfect case, we should have their involvement in the project as something that can speed it up but not block or compromise. Dependency on them is a warning signal.
Mid-level and Senior
They are in a spectrum of executing with increasing autonomy and designing with growing leadership. Identify their moments and provide structure on what they need to do accordingly. Naturally, most of the execution will come from these members.
Tech leads
Tech leads will have a proven record of designing and executing. The team needs to think carefully about what they will implement: why them and not a senior developer for this particular part? A common anti-pattern has them as a “faster senior developer”, not exploring their leadership. They should be challenged to identify the technical trade-offs and support the team in navigating them. Lead design conversations and clarify work for less senior people.
Undirectly involved
Stakeholders & Sponsor
The Stakeholders are people with interest on the product the team is working on. Among this group, there will be a sponsor. A leader whose scope is the one your project fits: your team leader or even yourself. This person is the first the team will escalate subjects they have little or no influence on,
Advisors
Whenever possible, it is excellent to leverage technical advisors. It is prevalent in large companies, and they can speed up decision-making, coach more junior members, or even review work. Ask about their availability and clarify what they can expect from people in this role to the rest of the team.
What if I don’t have all these people?
It is not a problem at all. In smaller companies or less mature teams inside big companies, it will happen that a single Senior or Lead+ will be the entire team for a particular skill set. Covering what less senior people would do if they existed is not a problem when it is a need. However, the opposite is a problem since it can set the project for failure.
If the team needs to develop an ambitious solution and the available people are too junior to even consider it a stretch, the project leader can consider playing the tech lead role or de-prioritize it to wait for a better opportunity to work on it.