What counts in R & D is the willingness to work in a changing environment, where it may turn out that you are typing CSS one day, and the next, you are working on adapting the graph algorithm to the project's needs. But it pays off - say Tomasz Świstak and Jakub Kubacki, who work in the R&D team at Synergy Codes daily.

What team do you work in? What is so special about it?

Tomasz: Our team, known internally as R & D, is most importantly assigned to many clients and projects. Our work usually involves caring for new clients' needs who have not yet decided on permanent cooperation.

Typically, our products are prototypes, prerelease products, or small projects. Due to the company's specialization, these are primarily web projects. Although it is also worth adding that our team also takes care of longer projects, where clients need so few resources that it does not pay to launch a dedicated team.

Someone who reads this description could associate our work with the title of the film Everything Everywhere at Once. Still, contrary to appearances, our work is coherent and essential from the company's point of view, especially for the sales department with whom we work directly.

Jakub: Synergy Codes is a software house. Here we mainly work on dedicated software for our clients. Typically, one team works on one project for one client, even for several years. In R & D, it looks different.

Sometimes someone comes with only an idea for a product and looking for financing. Then a lot of work lies on the side of the design team, which helps the client to develop the product concept. The most important functionalities are then implemented by us, creating a POC/MVP. With a clickable, working product in hand, it is easier for our clients to attract investors and start a long-term project.

But only some of the MVPs we do are fighting for funding. It happens that customers come to us to try out a solution. As a company, we focus on data visualization, particularly diagrams, which is the issue most often addressed by customers. Some time ago, we had a client to whom we had to prove that we would write a diagram presenting several hundred sensors. This was achieved quite recently. The company signed a several-year contract with him to further develop this project.

Due to our focus on diagrams, we also have consulting projects where we need to help a client make their diagram work.

It also happens that the client is Synergy Codes itself. 🙂 When there is a need to identify new technologies or develop internal projects, our team is here to help.

You both have experience working in client teams. How is it different from working in R & D teams?

Jakub: There are several differences, but the scope and duration of the project have the most significant impact. In long-term projects, you work in one technology on one business issue for an extended time. If you wrote code for an ice cream cone factory in Angular in March, you'd also do that in April. In R & D, the next month will bring a new client, new business and industry vocabulary, and new technology.

The overall scope of the project and how it is delivered also affect how the software is developed. Scrum governs long-term projects, and sprint scope is primarily rigid. In our case, we adapt the process to business requirements. Sometimes you can say that we work in Scrum, sometimes in Scrumban, and sometimes in Waterfall - everything is possible.

I forgot the most important thing. In client teams, usually, the entire team works on one project. In R&D, we break this pattern and work in groups of several people. As a team, we work on several projects at the same time.

Tomasz: The main difference from my perspective is diversity. Working for one client, you know the product well, the secrets of the code, and what the other party expects. There is no such thing here. Instead, we have contact with new technologies and get to know various industries and their needs.

Generally speaking, you can't get bored here because even if you do not work for any client, there are still plenty of other things to do. You must be very open-minded. No one who is, for example, a fanboy of React and does not even want to think about starting something else will stay on our team. With us, as a React specialist, you can get into a project with Vue or Angular.

Of course, there are preferences, and we stick to them, but sometimes the knowledge that someone has from outside a specific framework may be more important from the project's point of view.

Since technologies are changing or mixing, how to unify knowledge in the team?

Tomasz: The exchange of knowledge occurs in three ways: through meetings, written communication, and a shared code. In terms of meetings, we have a daily meeting, where we exchange information on an ongoing basis, what is happening in projects, and monthly technical sessions, where we discuss projects and what technically exciting things we had the opportunity to do there. In writing, of course, it is constant communication on Slack and sharing various documents on Confluence.

On the other hand, the shared code is what we internally call a "component library," although it's not something like Material or Ant. It is more of a form where we have many mini-apps that present various interesting, advanced features that we had the opportunity to create. It is worth adding that while Angular and React skills mix, the core of our team that brings us together is the GoJS library, of which Synergy Codes is an official consultant, and it is in our team that the main knowledge about it is concentrated.

Jakub: In an ideal world, each team member would know everything about all the functionalities that all members developed. However, this is a perfect case impossible to meet. Nevertheless, knowing what we have managed to create and what problems we have solved is fundamental. We can solve problems more efficiently and deliver functionalities faster using collective knowledge.

So much for the theory 🙂 In practice, we would like each team member to know what projects we have implemented and what they were about. Joint daily and regular technical meetings are essential here. The latter is a space for presenting individual projects and discussing more exciting implementations.

However, this approach has the disadvantage of requiring participation in meetings. Everyone needs to remember to click the record button, and playing meeting recordings is only sometimes an effective way to acquire knowledge. Therefore, we are working on standardizing project documentation in addition to technical meetings. We also create a library of ready-made solutions, thanks to which we can deliver value to customers faster.

But the most important thing is the atmosphere in the team. The term "young and dynamic team" has already become a meme, but there is something to it. Of course, the team doesn't have to be "young" or "dynamic," but it should support its members. An atmosphere of psychological safety makes it easier for people to open up, ask for help, and clash ideas.

While we're talking about the atmosphere, do there sometimes be conflicts in the team due to frequent changes?

Tomasz: Unfortunately, this can always happen. We always try to recognize projects and clients so that even if someone, for example, does not know Angular well, he can find himself in the project because he could only work on GoJS. However, customers and their needs are different, and suddenly it may turn out that someone needs to feel more comfortable where they are.

Over the years of our team's work, we have already acquired various experiences, including negative ones, but we always try to conclude such cases so as not to repeat them. Such a lesson for us was not to delegate only one person to the project but always try to find space for at least two, even if they would not work for the client full-time.

Here, too, I can add a simple story: as a team, we once started an internal project, and we were equally React and Angular. So what did we do to avoid conflict? We created a project in Vue so that everyone can complain equally.

With such volatility, can there be situations without a project?

Tomasz: Of course, there are downtimes when there is no work for an external client. Then, however, we have an internal client, i.e., Synergy Codes. As I said before, you can stay engaged with us. Working for clients is the most important thing. Still, when there is no such thing, we have a lot of tasks, such as maintaining internal projects or more significant participation in guilds, which are primarily aimed at developing the company's competencies. This is a good use of time because, thanks to this, Synergy Codes, which focused mainly on GoJS, entered other development areas in which it acquires customers. And not only focused on data visualization, and what’s more, not even on front-end development.

Jakub: It happens that the whole team is overwhelmed with work. But sometimes people have slow runs. We call it a "bench," and we use this time mainly for internal purposes. We recognize new technologies and solutions and organize what we have already developed.

If you call yourself the R & D team, where do you get the "R"? Does the mentioned "bench" stand for Research?

Tomasz: Our research is carried out in several ways. Of course, the "bench" is one of them - as I mentioned, we have development guilds and internal tasks in technology reconnaissance. However, research is also for the needs of client projects.

To explain it well: front-end projects aren't so typical. It's not just "make a form," "make a table," or "make a funnel." For us, the front-end is primarily data visualization. And here come some interesting algorithms. For example, we have a project where we are supposed to visualize data from a graph database. The client wants to display and automatically position up to 50,000 entities simultaneously. Then, if this is the first time, we have done something like this, someone needs to research what algorithms will be able to do it quickly here and how to force the browser to calculate it quickly.

Can people working in groups on different projects be called a team?

Jakub: Yes. Although, sometimes, it is different with our "team sense." Even though we work on various projects daily, we pursue the same goal: to support our clients' businesses.

Let's also remember that the projects are pretty short. As a result, project groups mix, and usually, everyone has the opportunity to work with someone else.

Apart from that, we are also quite well integrated. Despite one of our teammates living in Szczecin, we meet at the office at least once a month. We run joint daily and know what is going on in each project.

You start new projects - what new things can you expect?

Tomasz: From the point of view of the organization and the team, there is an opportunity to use new or simply different approaches, libraries, or frameworks. As R&D, we introduced functional programming and NodeJS backends to the company, first Express and then NestJS; on the front end, we had Vue and Next.js for the first time, and we also started to recognize novelties such as Solid.

Also, as I mentioned, we specialize in visualizations using GoJS, but we are constantly open to alternatives, e.g., recently, part of our team has been working hard with React Flow. As part of R&D, we also worked out how to create a Miro-style real-time collaboration on a diagram. In the context of novelty, we have already gone through several different approaches. Now, thanks to newly available solutions, we have managed to enclose all the knowledge within a minimal front-end code and a relatively simple backend.

In addition, in the context of novelties, we can observe in our own way what is new in the technology market and what startups come to us with. For example, when there was a blockchain boom a year ago, we were dealing with a project from the crypto world.

Jakub: Historically, apart from library and framework version changes, the most visible thing is the return to SSR technology. This approach once dominated the market and was replaced by SPA. Today it is gaining popularity again.

New libraries and frameworks are also created in this direction, for example, Next.js.

Is working in an R & D team for everyone?

Tomasz: Absolutely not. Just as people like to laugh at "young, dynamic teams" in their job offers, the dynamics are significant here. We must constantly learn new things, be open to the diversity of the JS world (and not only!), and also be able to avoid getting attached to projects. An enthusiast or someone with a specific development goal will find a place here sooner than someone who comes to work for 8 hours, and that's it. I do not want to say that we work longer because it is not so - we care about work-life balance, but I mean more about the approach to work. Hardly anyone here would like to do the same thing every day without feeling any satisfaction from their work.

And in terms of experience, our team characterizes a complete cross-section of seniority: juniors, middle, and seniors work with us. What counts is the willingness to work in a changing environment, where it may turn out that one day you are typing CSS, and the next you are working on adapting the graph algorithm to the project's needs. But it pays off. Even if they started as front-end developers, people from our team began to specialize in other directions: backend development, machine learning, DevOps, and architecture, and these are just a few examples.

Jakub: The way we work is specific. If someone likes stable projects, such work can be tiring. I have a somewhat chaotic work style and feel better in an R&D team.