How to Scale Your Alerts Beyond PromQL with Coralogix Flow Alerts
When building alerts, engineers aim to create accurate, timely, and actionable alerts. In pursuit of this goal, many engineers will leverage PromQL throughout their careers. PromQL…
Whether you are just starting your observability journey or already are an expert, our courses will help advance your knowledge and practical skills.
Expert insight, best practices and information on everything related to Observability issues, trends and solutions.
Explore our guides on a broad range of observability related topics.
The Cambridge English Dictionary defines a silo as “a part of a company, organization, or system that does not communicate with, understand, or work well with other parts.” Siloing can exist at various organizational levels: siloed departments, siloed teams within a department, and even siloed engineers within a team.
In any industry, siloing can cause issues with alignment, communications, and overall delivery, but in fintech, there are additional risks.
The financial sector, by its nature, is heavily regulated and fault-intolerant. This means that developing anything in the field naturally costs more and comes with higher risks than building in other industries. The more costly mistakes and misalignments are to fix, the more critical it is to address siloing quickly and decisively.
Fintech is also fast-moving & highly competitive. An organization where everyone is working towards a common mission has a competitive advantage over one which is siloed, with each department working towards its own isolated goals.
Remote working has become more prevalent in the last couple of years, posing its own siloing and communication risks.
When workers are colocated, especially in an open-plan and cross-functional office setting, you get communication ‘by osmosis:’ people overhear and interject into conversations organically. In a remote setting, relying exclusively on formal meetings to discuss upcoming work often leads people to be left out of discussions that aren’t related to their team.
Compounding this issue, in a remote setting, it’s far easier to tune out of a meeting because something more interesting is happening or because of video call fatigue. This can lead to people missing out on vital information.
These issues may sound insurmountable, but with a few simple alterations to your workflow, they’re quite simple to address (more on that later).
The most crucial step towards addressing siloing is to identify it. There are some tell-tale signs that your fintech organization is siloed, but for this article, we’re going to focus on the red flags around the tech department.
Let’s start at the individual level. How do we know if engineers & DevOps staff are siloed from each other?
The first warning sign is “talk to Mike.” “Mike” might have a different name in your team, but if every query about a product or system in an organization is redirected towards one or two long-term employees, this is a warning sign that knowledge sharing isn’t happening effectively.
The next warning sign is that the Slack (or Discord or IRC) channels are quiet. This generally means the entire discussion happens in meetings where not everyone is involved or in private messages where not everyone is included.
Finally, ‘rubber stamp’ pull requests. If the expectation is that pull requests are reviewed or approved in ten minutes, then it’s doubtful that engineers or DevOps are properly reading them and understanding them. Rushed peer reviewers will quickly check for the most critical issues, rather than understand and question architectural and functional decisions.
What about at a higher level? How do we know if teams are siloed from each other?
This is quite simple, ask the engineers on one team what another team’s current goal is. If they don’t know, it’s probably because there isn’t enough communication between the teams.
Understanding whether the entire tech department is siloed is slightly more nuanced. There are three major symptoms that you can look out for, though.
The first, very common, red flag is that engineers refer to other departments as ‘the business.’ This phrase may sound harmless, but it suggests that your tech function sees itself as outside of ‘the business,’ just delivering functions it has no input into.
The second is that teams know ‘what’ they’re building but don’t know ‘why.’ Not just ‘why is this useful?’ but ‘why is this the highest priority for the company right now?’
The third is that teams know ‘why’ they’re building it, from the company’s perspective, but don’t know ‘why,’ from the user’s perspective – how the feature adds value for the people using it.
Having identified the fact that there are silos, the most crucial tool to breaking down walls – whether between individuals, teams, functions, or departments – is better communication. This doesn’t mean doubling up on video calls, which will cause more irritation for the employees we depend on to support the changes.
We’ll list some changes you can make from easiest to hardest. This isn’t an exhaustive list but a solid foundation for better communication.
First, where possible, everyone should be encouraged to discuss things in the most public relevant forum. Instead of an engineer asking Mike how the futures trading product works in a private message, discussing in a public channel allows the entire team to share and learn simultaneously.
Following up on this, introducing and encouraging the use of assets like a company wiki can be extremely valuable. The easiest way to communicate something comprehensively is to write it down once instead of writing or saying it over and over again.
Documentation takes time to create and must be actively championed, but repeating the same thing in tens or hundreds of conversations takes even more time and gets tiresome.
Next, enforce regular company-wide updates. These can be a meeting or an e-mail with a short update from each team and department on what’s been accomplished recently and what it’s working on now. This is also an excellent opportunity for leadership to explain what’s coming up and why it creates value for the customer.
Knowledge sharing sessions can be another valuable option, where one employee (or contractor) delivers a presentation about something they’ve learned recently to the entire tech department. This offers a forum to talk about new technologies, new applications of technology, or even things like environmental impact or accessibility.
Then there’s mob programming. Have a 90-minute session once a week where an entire team works together to build a feature or fix a bug. This helps create more team communication and allows everyone to discuss things beyond the feature at hand.
There’s a lot of value in establishing a ubiquitous language. This is a concept taken from Domain-Driven Design, which simply means that everyone in the business speaks the same language. If the business defines a ‘quotation,’ an ‘option,’ or an ‘FX trade,’ that should mean the same in engineering.
This isn’t just about naming variables and functions. It’s about everyone growing their understanding of the business and its customers.
Several fully remote companies have succeeded in having a ‘team week,’ where the team gets together in one location for a few days to work together during the day and bond as a team during the evening. This can help break down barriers between teams and departments as engineers & DevOps staff socialize with people outside of tech.
Finally, building true cross-functional teams is a great way to increase knowledge sharing across disciplines. Essentially, they’re teams built from multiple disciplines – a product owner who understands the product from a business perspective, a quality assurance expert or developer-in-test, a platform specialist or DevOps, a UX/UI specialist, etc.
If you want knowledge to move further, swap one person out of each team regularly. This will help bring knowledge gained from one team to another team. It’s important not to do this too regularly, though, or there will be a loss in productivity from people having to keep onboarding repeatedly.
The key to breaking down silos is building an organization where people are excited to talk to each other. If your organization is heavily siloed, that will not be an overnight fix, and you will need to attach value to, and prioritize, communication and knowledge sharing.
Understanding that tech is not an independent function from sales, treasury, legal, or any other department is essential. Engineering and DevOps staff should always consider the user experience. Automattic, the creator of WordPress, famously requires all of its staff, from the CEO down, to spend a week of each year working on front-line customer support!
The world of fintech is fast-moving, with plenty of pitfalls and traps to fall into. A team working together towards a common goal, where everyone feels heard, is the most equipped to thrive in the industry.
When building alerts, engineers aim to create accurate, timely, and actionable alerts. In pursuit of this goal, many engineers will leverage PromQL throughout their careers. PromQL…
Stateful, commonly monolithic, and absolutely fundamental to system design, the quality of your database administration and operation is a key determinant of your overall success. Databases…
Like cloud-native and DevOps, full-stack observability is one of those software development terms that can sound like an empty buzzword. Look past the jargon, and you’ll…