It’s an article on how one hybrid role within a team entails further changes and extends the scope of other roles. It’s not a story from the Silicon Valley or a fancy IT magazine – it’s just about daily work in a team, where members understand distinct roles, and are not afraid of carrying on the tasks that go beyond the scope of their current roles.

This could be a post about a business analyst (the author of the article) who becomes a tester during a sprint or a tester who is also a developer, yet it’s rather about the very mindset which is to see the bigger picture while building a product.

Hybrid Role – What is it?

There is much hype about hybrid roles in the professional world. If you already know this buzz word, you are probably familiar with the related words: fast-growing, high-earned, hard to fill. In general, a hybrid role requires a wide set of skills from different fields, so your colleague who is a mixture of technical and people’s skills is definitely a hybrid. Moreover, a developer who has a good understanding of the design fits into the hybrid role. These positions are complex and difficult to be automated. According to a report by Burning Glass, 42% of normal jobs can be automated, but only 12% of hybrid jobs can, which makes them quite unique and difficult to be replaced. More than half (54%) of all current IT jobs require some form of a digital design, while 26% of technology-related jobs require static design.

Jobs
Hybridization level
Automation likelihood
Data engineer, IT auditor
Very high
12%
Health information manager, cybersecurity analyst
High
26%
General auditor, medical biller
Moderate
42%
Machine operator, truck driver
Low
48%

Source: Burning Glass Technologies

The demand for hybrid employees is getting higher –  fundamental knowledge from one domain will still be required, however, it needs to be supported by a wider look at other parts of the system – the system thinking itself.

Source: Burning Glass Technologies

Our Team – What does it look like in practice?

When I first heard that SDET would join our team, I didn’t even know what this acronym stood for. Don’t google it! It’s the Software Development Engineer in Test. I thought that it was a one-man army and I was quite sceptical of the advantages of this solution in practice after all I heard about the differences between the developers’ and testers’ world.

In theory –  it looks perfect, you have a team member who can take a developer’s task at the beginning of a sprint, and once there is something ready to be tested – he or she is able to switch. In practice – it works, but as always there is room for improvement – mainly from the SDET perspective, because he is still associated with a tester (sometimes too often). It’s helpful to determine the development and testing ratio for the SDET. In our case, it is 20% to 80%.

In this team set up, an additional effort is required from developers because they are involved in creating end-to-end tests. In the current case, they dealt with all these tasks without any complaints, however, they were still supported by  SDET.

From my Business Analyst perspective, it opens a new door. During a sprint, once there are some stories to test and when I have some spare time, we share testing between BA and SDET. I take over manual tests and he or she can take care of automation tests. As a result, the entire process is speeded up.

What is BA’s benefit?

As an analyst, I gain some technical knowledge, which results in higher awareness of the details of my team members’ work. Moreover, I’ve realized it’s beneficial for myself because the team does not only perceive me as a person who represents the business world. I’ve noticed we discarded the following old-fashioned slogans: “I’m not a technical person” or on the contrary: “I’m only a technical person –  I don’t know what the business wants”. Thanks to the fact that we understand different perspectives better, we are now able to see the bigger picture while building a product.

Perhaps, in the nearest future there won’t be the business analyst role as we know it today. That’s why I’ve taken part in an angular training course recently 😉. I believe that you’ve taken advantage of working with the hybrid role in a different way than I did, so please share your thoughts on how the hybrid role has changed your team.