Eva Belyaeva, Head of Product Development at Security Vision
Introduction
In this article, I'd like to share a non-obvious life hack for maintaining team performance at a relatively consistent level over the long term. In my work, I encountered a situation where the team I was entrusted with had somehow grown significantly in size without me noticing, and the question arose of how to establish communication within it. The challenge was to seamlessly integrate interactions between engineers into the workflow and build a support network without forcing people to communicate.
Bad Practice: Befriend to Work
Many years ago, I experienced a rather unpleasant period in my work, from which I could only draw conclusions about how not to do things. This anti-example or anti-pattern consists of a company or team that stymies a person, effectively preventing them from completing their work within the process. For example, a person is expected to use the work of their colleagues in their own tasks, but they have no leverage over these colleagues; moreover, these colleagues have their own, higher-priority tasks from which they are difficult to distract.
In such a case, the person simply can't get their work done – they can only wait, or worse, constantly escalate the issue. A structured process would have solved the problem, whereby the other party would prioritize these tasks and allocate time for them. But in this case, the issue was resolved differently: we made useful connections with colleagues on the other side of the issue, and they began making exceptions for us, meeting us halfway, and helping us with our work.
Something is obviously wrong with the processes when you have to build good relationships just to get people to do their jobs. The problem isn't doing it at all; the trouble begins when nothing works without it.
Why this is bad and doesn't work in the long run is also obvious: you can't just do your job if you've had a conflict with someone. The work is guaranteed to be incomplete and depends on personal relationships – someone might not like you, or you might not like someone – and this somehow affects how well you perform. Even with people you find unpleasant for some reason, it should still be possible to build working relationships that don't require intrusion into the other person's life.
However, the communication problem is bigger and deeper.
Communication problem
Despite the negative side of the previous approach, the problem remains: people are afraid and embarrassed to communicate, especially at work. Sometimes the simplest work tasks drag on for days, if not weeks, simply because someone is too shy to ask another person a question and is stuck tackling everything alone.
Even good or neutral relationships don't guarantee effective communication – sometimes fear or embarrassment prevents people from doing what they believe they might reveal to others: their incompetence and inability to understand the issue, even though this is not the case. Such problems threaten to miss deadlines and produce substandard work, and generally indicate that employees lack a crucial skill for their work: the ability to accept help.
Even if the employee is open to sharing their experience and knowledge, even if the process is structured in such a way that the chain of escalations leads to this employee and assistance is part of their job responsibilities, it is still necessary to teach people on the other side of the task how to use this "work tool" wisely.
Soft skills are also work
Any interaction, whether within or outside the team, is a skill that needs to be developed. Moreover, over time, we began to realize that it would be much easier for employees to perceive such interactions as their own work if we, on our part, honestly labeled them as genuine work tasks.
For this to work, we must never demand good treatment from employees that goes beyond work – like friendship or camaraderie. Our goal isn't to bring people together, but to remove barriers between them and prevent prejudice from festering.
People need to be able to negotiate and invest time in it. Without establishing contact upfront, even though it requires commitment and time, subsequent tasks won't be accelerated or simplified. In this case, it's always worth thinking strategically, planning the effectiveness of the actions introduced not immediately, but in the foreseeable future. We've identified some patterns characteristic of our processes; your figures may differ: establishing communication between 10 people on a team took a quarter, while for 20, it took six months.
Establishing team collaboration should come from the top, from the company and management; it should become a policy. We had a policy of openness and engagement from the very beginning, but we still had to modernize our processes: our numbers had grown significantly, and even though we were still co-located, we had to make an effort to maintain contact.
If we're talking about a single team, then collaboration within it will grow organically with proper task setting and role rotation for the employees involved. On the other hand, cross-team collaboration should be driven by processes; personal factors such as likes and dislikes should be eliminated, and the focus should be on work-related issues.
Where applicable
In general, building relationships and removing barriers is essential everywhere. But here's where our internal networking approach is or could be beneficial:
· The SOC and teams within each line (if any) help resolve operational issues and conflicts in advance, before a problem arises during escalation.
· Development teams – when separating development areas, it's common for an employee to only know their own area well, but to complete tasks efficiently, they need to know how their code will impact all other functionality.
· Administrative teams supporting the SOC – so that they know each other and understand who to contact with any questions that arise.
The main goal is that people should not be afraid or embarrassed to ask questions of their colleagues and offer advice when requested; they should understand who they work with and what knowledge they possess.
How to make this an internal company policy
We've developed several scenarios for implementing this approach into everyday work life – from meetings to tasks, from serious approaches to gamification.
1. Communication and mini-teambuilding.
Once in a while, always during work, we gather the whole team for a small team-building session. The goal is to learn more about each other in a comfortable setting and learn how to interact with different team members, laying the foundation that will allow them to feel comfortable asking for help in the future. Before introducing such an activity, it's important to understand that it's a process.
The ultimate goal of these meetings is to discuss current issues and constraints on other, "legal" tasks, but achieving this can take a long time. It depends on the team size, composition, and objectives. For us, it took about three months for a team of 10, and six months for a team of 20, to move from unconstructive to constructive discussions.
It's normal for a meeting to be used as a place to vent, complain, or brag. It'll take some time to release all the intense emotions, not necessarily negative ones, and share something about yourself with others. The key here is to not retreat when it begins to feel like people are simply relaxing for an extra half hour or hour – in fact, this is far from the case, and at the very least, switching to socializing and internal networking helps recharge.
When conversations inevitably shift to a strictly business-related level, to maintain the informality of the meeting, you can move on to a change of scenery and context – move the meeting to a park or break it up with a light warm-up.
If you experience moments of crunch (who doesn't?), these meetings are also useful because they provide a guaranteed haven of calm amidst any deadline – every employee needs a break from time to time, even when everything is on fire. Moreover, when meetings begin to feel like a safe haven, this attitude will transfer to other colleagues present. Therefore, all other things being equal, priority will be given to your team and your team's opinions, which is important in some situations.
2. General work activities in a game form.
One of the articles on business simulations describes this in more detail. But in short, we simulate scenarios for working with our products from both the customer and partner perspectives. This often helps during brainstorming sessions for product features and testing the final results.
Moreover, this allows us, firstly, to better understand what we're doing and how it should work – what is expected of the product. Secondly, it gives us an understanding of why and for whom we're doing it – use cases, especially those tested with real customers, provide the feedback necessary for development.
3. Joint tasks for exchange of experience.
Even though our large team is divided into subgroups, we generally share the same foundation. Our team members also have varying talents: some are good at analytics, while others are adept at writing complex queries. Encouraging people to share their experiences is crucial to avoiding major imbalances within the team. Rather than setting tasks like "teach A to do B", pair people up or group them together, where one person has the most knowledge on the task, while the other needs to learn.
We practice various forms of pair programming, as far as possible when programming in the no-code format, and we implement cross- reviews not to scold someone or point out mistakes, but rather the opposite: the reviewer can actually learn something new, a new way to solve a classic problem, or a different approach to the process as a whole.
In other words, if people are forced to spend time together for a common cause, over time the efficiency of the entire team will inevitably increase.
Building relationships is a real goal beyond the obvious "getting the job done" and "meeting the deadline," shifting the focus from the quality and effectiveness of work to the quality and effectiveness of relationships, which inevitably leads to an improvement in the former.
Paradigm shift in interaction
Our goal is to move from the paradigm of "there's someone evil and weird out there, I'd rather handle it myself than go to him" to the paradigm of "there's an engineer with a cool cat, I think he knows how to write SIEM queries, I'll go and ask."
In other words, we transform this:
In this:
As a result, instead of anonymous names, an entire system is built before the employee, a “support network” of familiar and understandable colleagues who not only should help him in his work (as he does them), but now also do not seem unattainable and strange.
This is precisely why we use all the above-mentioned methods of collaboration and hold meetings, inevitably bringing people closer together.
Results of the implementation of the practice
A brief overview of the results. Some of these bonuses appeared almost immediately after implementation, while others required a bit of time.
Redistributing workload and tasks made it possible to manage each employee's time more flexibly, and the workload became more transparent – people were no longer afraid to speak up when they weren't getting something done or when something didn't work out. Spoiler alert: they didn't lie either, because there wasn't much point in doing so – someone would come to the rescue and actively engage with the task, things would get moving anyway, and everyone's contribution would become clear.
Teamwork within the department – employees care even more about what's going on with their colleagues. We make products, and we make them together – this means our job is to do everything well, not just do a few things very well and turn a blind eye to the rest.
The overall anxiety level has decreased – that quiet haven has paid off during times of crunch and a deluge of tasks. Now, almost any need to "up and redo everything" or "get it done urgently for the presentation in two days" is less pressing – people know they'll have both time to recover and time to rest afterwards. And, frankly, after sharing our experiences, we've realized that we've significantly reduced unnecessary overtime – if someone previously sat with a problem for two days and felt sad, they could now get help within an hour.
Understanding interactions makes the team's structure more transparent. Another nice bonus: occasionally swapping roles helps you better understand what your colleagues are doing. Basically, it becomes clear that your colleague's work isn't trivial and is just as complex as your own, if not more so. Sharing tasks helps you avoid devaluing each other and adequately assess your contribution to the overall project.
How has work changed?
Previously, requests for help and insight into what was going on with others arose somewhat chaotically – people would turn to former colleagues they knew before, or to those they had studied with – basically, they would find those with whom they had something in common before joining our team. But a safe and familiar person doesn't necessarily mean the most competent in this matter. Yes, two heads are better than one, and bringing employees up to the same level of competence helps, but it's still better to ask someone who understands the issue more. Surprisingly, many of us were more afraid to ask for help than to provide it, even though everyone was eager to approach, delve into it, and demonstrate their capabilities. This energy literally needed an outlet.
Through a series of meetings and task sharing, we've developed a clear structure for requests and escalations within the department at a horizontal level – we know who's good at what, how busy everyone is, and what problems they're facing. You can clearly ask the right person a question and receive advice and assistance, or, in a free moment, browse the help thread and explain or configure something.
An expected benefit: fewer questions were escalated to leads, and the flood of identical questions from different people also disappeared. Now everyone was interested in what was happening across the various product teams and began to remember first the problems we encountered, and then the solutions.
I won't hide the fact that, first of all, this relieved me of a lot of work, but ultimately the whole team benefited from it.
We solved more problems together, which resulted in more efficient results and improved work quality. When you're working on a task alone, especially if you're not particularly skilled at it, you're often happy that it's at least starting to work, and you don't always have to go back and refactor it. Here, when we went through all the subsequent steps separately and shared our expertise, we were able to complete some tasks perfectly on the first try – well and to a high standard.
Furthermore, thanks to communication and discussions, we found multiple solutions for each problem instead of just one or two, and we even had time to test them to understand which was effective in which case.
Conclusions
Soft skills are work.
Networking is a task like any other, no less important than any other engineering or analytical task.
The point of introducing informal communication during work hours into the work process is to stop forcing people to establish connections in their free time without providing any tools or leverage for doing so.
Trying to change your work format requires a relatively long wait before it begins to bear fruit, but the end result is worth it.
.jpg)
