Software Development industry is a quite interesting and sometimes strange area of engineering. Everything is constantly changing, new approaches and frameworks are coming every day, and the word „hype” is often applicable. Nevertheless, the main principles and fundamentals of Computer Science do not change. Most of the technologies we use have had their fundamentals in place since the 1960s and 1970s. How can it be if we clearly live in the world of increased competitive pace, where everything seems constantly changing? One answer would be – by consciously building the teams in a smart way to have in-house capacity to maintain stability, keep up with the changes, and accelerate innovation.
A popular, but wrong assumption is to see large enterprises as some sort of big machines with a lot of bureaucracy and overcomplicated processes and compare it with start-ups, which look like small “Star Wars” rebel teams in comparison. But this is not a binary problem. So, let’s take a closer look at whether speed of innovation depends on the size of the company or not?
The important thing we should bear in mind is that software development is not a „thing-in-itself“. We deal with problem-solving – these can be customer, or business, or engineering problems, or this could be about trying new ideas with the goal of changing the world in some area. We have teams - teams of analysts, engineers, product owners, testers, operations. We want to build the teams in the optimal way to be successful. There are a lot of methodologies created for being effective - Scrum, Agile, Extreme Programming, and so on; all of these methodologies focus on happiness. Yes – happiness: happiness of customers, happiness of teams, happiness of stakeholders.
The famous Conway Law states that:
organizations which design systems... are constrained to produce designs which are copies of the communication structures of these organizations.
Even though lots of effort goes into optimizing the organizational processes for increased employee happiness, conflicts of interest are inevitable between the different roles – engineers vs QA, engineers vs operational teams, etc. The industry is actively rethinking the nature of these conflicts, even in the job role descriptions you can now often see extra expectations (e.g. the 10x engineer hype, more here).
Illustration credit: www.kovair.com/blog/the-battle-dev-vs-ops
Illustration credit: steemit.com/dev/@opticons/developer-vs-tester-qa
The thing is - people are different and an “ideal spherical engineer in vacuum” simply does not exist. To take the two sides of the spectrum, there can be a person A who is a great executor and prefers to have the plan predefined for him and decisions pre-made, and person B who thrives in chaos and gets excited by the possibility to experiment and make decisions. It is impossible to definitively say which one is a “better engineer”, A or B.
Interestingly, a strong engineering team needs to include both A and B type people to maintain a healthy balance between predictable execution and innovation/experimentation. The job of a good team lead is to make sure that every person gets a suitable environment and tasks, making sure that everyone is happy and that the team is balanced. (This is also the difference between the roles of a team lead and a tech lead, who’s mainly taking responsibility for the technical decisions being made by the team to be suitable and sustainable.)
Thinking of the Conway’s law, while a product mirrors the organizational structure, the same also applies for the creation of new products – so starting a new product, it makes sense to pick a team type/structure according to the expected product structure. For a project with lots of experimentation and R&D involved, vs for a clearly scoped product feature with product managers and plans in place, different types of teams and people will be the best fit – for the product to succeed and for the people to be happy.
In Playtech, we call these “rebel projects”, where curious-minded people from different teams and with different domain knowledge join forces to solve cross-domain problems, try new approaches, prove or disprove something. Inside these teams, we agree to work as a startup and skip the processes and bureaucracy to be able to iterate and move quickly. These are not always success stories and a certain element of risk is involved, but that’s not necessarily bad – sometimes proving some idea wrong can also be a huge benefit. But in Playtech, the success rate of rebel projects is quite high; two thirds of different rebel projects I’ve taken part of during my time at Playtech have succeeded. In my view, the level of a project’s success doesn’t purely depend on the level of complexity of a problem being solved (e.g. mathematical complexity), but also on the level of communication achieved and the ability to quickly iterate.
In the rebel projects, Playtech actively experiments with the new technologies and approaches, and the results are communicated back to other development teams, and also shared with the community. For example, we have good experience adopting machine learning to solving critical problems, applying an intellectual approach to the core parts of Playtech system (more here). Some of the findings become the basis for articles, conference talks, and even master’s theses – which is how Playtech contributes to sharing knowledge and giving back to the engineering community. This is a mutually beneficial process, with knowledge coming into the company, getting enriched, and then returned back into the wild.
When thinking of large companies like Playtech, it is often assumed these are slow-moving and process-heavy enterprises, but in fact it is possible for every person to find a suitable role for themselves, be it planned feature development or experimentation and R&D. While building the teams to be successful, it’s important to remember that success means multiple things – reaching the goals, increasing employees’ happiness, providing possibilities for personal growth and self-development, and so on.