It has been over 8 years since I started working in telecoms. This post has become a two-parter. Part 1 is a look at the interesting technical challenges around telecoms software. Part 2 has some reflection on my own journey. The summary is that if you have the option of working in telecoms, or any other real-time communication environment, I'd say go for it.
Part 1: Why Telecoms
...And is telecoms the right term?
Physical SIP phones in the 'lab' back in 2018
I like the word telecoms. I expect lots of software developers who have worked on VoIP platforms, or SIP integrations (or Microsoft Teams/some other UCaaS) might say they work in ‘Cloud Communications’ or similar. That’s fine, and is a more recognised and modern term, but telecoms feels inclusive of physical telephones, which adds a somewhat nostalgic touch.
Whilst we are talking terminology, telecoms is bigger than just SIP. However, SIP is the de facto protocol for signalling phone calls when it comes to most cloud communication platforms.
Web Software Needs To Be Reliable (Sort Of)
A somewhat patient web user
What’s so interesting about telecoms? Let’s start by considering the classic software development gig. That means developing typical create-read-update-delete (CRUD) software and APIs, probably bundled up in some web portal.
Nothing wrong with that of course. Those systems make the world go round. However, it’s often not particularly high stakes or exciting, unless you are running a particularly large operation.
Visiting a web page and experiencing a slow load time, or seeing a
404 Not Found or some other error isn’t crazy unexpected to the
typical user.
I’d suggest anecdotally that anyone who encounters such an issue would likely
try a page refresh without giving it much thought,
especially if it is a site they’ve used before or the only available
option for what they’re trying to achieve.
Your typical user is somewhat forgiving for web pages having ‘blips’.
Developing Software on Hard Mode
When it comes to telecoms, users are less forgiving. A typical user expects to be able to pick up their phone and successfully connect to the number they dialled first time. There may be some minor allowance for outlier scenarios, e.g. calling a mobile user who is actively on the move in patchy signal, but even then I’m not sure the user expects anything but a successful phone call nowadays.
From a SIP software perspective a phone call is a set of signalling messages and audio packets flowing back and forth. If your platform is in the call path that means your service will need to:
- Handle the ‘call this person’ request/response(s) successfully (
SIP INVITEdialog) - Negotiate streams of audio/video, potentially many streams (think dialing into a conference call)
- Handle any in-flight requests (think going on hold, call transfers etc)
- Tidy up the call cleanly at the end (
SIP BYE). Almost as important as the initialINVITE; you need to know when to stop sending audio - Keep the media flowing promptly throughout
It’s perhaps clear any call path software needs to be performant and reliable for the user to have a seamless experience but the technical challenges don’t stop there.
Upgrades
You’ll need to engineer a way to do seamless upgrades. Some languages have this baked in, e.g. hot swapping code in Erlang, a language that was made for telecoms. I did work for a while with Kazoo which is PBX software written primarily in Erlang - an interesting project.
If not in the language it is an application design consideration. e.g a SIP aware load balancer can mark a node as down and slowly allow all the calls to drain (finish as normal) until the call count is 0, then the upgrade can commence.
High Availability
Related to this upgrade path, software and servers go wrong. There’s no batch processing here, no time to fix the issue. If a call is failing to connect due to a broken server/service it needs an alternative route right away (see the next section for a good reason why). DNS SRV records come into play here as one mechanism to advertise a list of services in a priority order. You then need to design and build your services accordingly.
For example, the main Microsoft Teams direct routing endpoint makes use of SRV records to give a set of priority ordered servers. That set also has another dimension, as the servers change depending on where you are in the world. Any software in the call path wants to ensure latency is kept to a minimum.
It's Not Life or Death?
Continuing the technical challenge angle, the stakes are legitimately high! It’s not just an intangible middleware service you are trying to build and support. There is a very real physical outcome in most cases; two people are now talking with each other because of you. The phone call might be super important!
I remember being at a team meeting once and there was some discussion about the stress of running and maintaining some call path components. Someone said, “We shouldn’t worry too much, it’s going well, and it’s not like it’s life or death!”. Except that isn’t quite true, if you’re in the call path and part of a regular user’s telephony experience, sooner or later someone is very likely to place an emergency call that runs through your platform.
You Want (Good) Challenges
The idea behind the above comments is to show that building and running software in telecoms, especially in the call path, is not only technically interesting and challenging but also rewarding.
I believe all engineers enjoy their job more if they are writing software that is used and brings real value. Software in the call path has a very tangible way of doing that. You can literally see the number of minutes your platform was used for people to communicate.
Part 2: Reflections On Telecoms In A Start-Up
Story time: I joined Qunifi back in 2017, a new startup that was looking to innovate in the telephony space. I didn’t particularly set out to work on communication software. In retrospect, it was a well-timed move. Not only for the technical reasons above, but it was perhaps a pivotal point in the industry. 2017 was the same year Microsoft Teams launched, which went on to be Microsoft’s fastest growing app ever. This is before we even get to the remote-first shift accelerated by the pandemic.
Qunifi built various cool bits of tech but is most known for building Call2Teams, an add-on that allows a cloud or on-site PBX (aka phone system) to be linked to Microsoft Teams in minutes. This means when a user receives a call it will ring in Teams just like a desk phone.
As an aside, I’ve always liked the name, I think patio11 (Patrik McKenzie) would approve. The name might be considered somewhat boring, but it does clearly state the product’s function. Call2Teams is fundamentally a way to send phone ‘Calls in to Teams’ (well, and out from Teams).
Startup Life
I was hired at Qunifi as the first software engineer employee. That meant I was right in the middle of helping the company design and build the Call2Teams platform, which then led on to scaling it up to over a hundred countries and millions of users. We also won a bunch of awards along the way such as this 2022 SaaS Award.
Guerrilla marketing hoodies to start interesting chats at tech conferences.
A startup has a tendency to magnify the job experience. All those well understood points in your industry, such as telecoms’ need for reliable software, high availability and seamless upgrades, all still apply. Except you’re shipping software to try and make a business start and grow, not just maintain your position. All of that with a background of low resource.
Perhaps this blog post is really recommending telecoms in a startup, if you can find it. That way you get to help design and build the product from the ground up and dig deep into all the interesting technical challenges.
Startup life is definitely not for everyone. The chance of success isn’t very high. If you do manage some early success that just creates its own set of new (scaling) problems. Scaling up Call2Teams was simultaneously exciting, challenging, and stressful. All sounds a little cliché, but it’s true. I think my feeling towards the ‘hard’ scaling years (say 2019-2021) has softened over time, perhaps because memory is more of a reconstruction, rather than a recording.
The original Qunifi team: Rus, Mark, myself, Richard and J, pictured at a Dstny event in London, September 2023.
You also want to optimise your choice of startup for people who are good to work with, not just an idea that you think might be a success. Qunifi had a small but great early team. You need that to pull everyone together through the difficult moments. You want smart, pragmatic people with an optimistic edge. Imagine a company that is struggling for product-market-fit and getting near the end of its runway - you need a good team for a fighting chance of survival in those sort of situations.
Qunifi to Dstny
UCToday had a post with this enjoyable image for Dstny acquiring Qunifi.
Qunifi was acquired by Dstny in March 2022 and the platform continues to be a success under Dstny’s care.
This is perhaps a trend that many employees notice post-acquisition where a startup is subsumed into a bigger firm, but there is a gradual change in the pace and approach for innovation. Possibly related to that, the job roles tend to become more defined.
None of this is necessarily a bad thing, but it is good to understand the nature of the business’s mission will likely shift - after all you’ve got all new shareholders who have their own plans. Change is the only constant.
Earlier this year I was featured in the Dstny ‘meet the team’ series of blog posts. If you’re interested in more of my own specific experiences in Qunifi/Dstny then that’s got some answers. You can reach out to ask me the questions you think are missing.
J, who was CEO of Qunifi joining mid-2020 was interviewed for a podcast that also talks about the journey from a different perspective. From 4 to 70: Scaling A Remote Organisation From Zero To $20 Million ARR with Jeannie Arthur.
Post Dstny: What Next?
I’m proud of the Call2Teams product, as I’m sure all the team that worked on it will be, especially those in the slightly crazy early years. It’s time for a new challenge though. From October 2025 I’m no longer working directly with Dstny but focusing on Haptap and Goldbyte projects. That means a break from building critical in-the-call-path software, but we’ll see how long that lasts. Haptap has a lot of interesting things lined up all around Microsoft Teams calling. I’m pleased to still be working on innovative software in the telecoms space.
Further Reading for Startups
For those unfamiliar with Paul Graham’s essays they give a fairly accurate and perceptive view of startup life. Albeit slightly tilted towards the experience in the US. In a draft of this post I started quoting the bits I felt most applied, but I think there’s probably more value in just directing you to the essays. They are very easy to read. Here are two recommendations specifically on startups: