Marten Schönherr, Automat Berlin: Partnering Telcos with the Developer Community

Establishing a solid relationship between the global developer community and telecommunications companies is not easy at the moment. As the installation and expansion of 5G networks continue to advance steadily, however, there are reasons and opportunities that encourage both sides to reconsider a partnership. So how do you convince a developer to enter into a partnership with telcos? And how do telcos benefit from partnerships with developers? We asked Marten Schönherr, founder and managing director of Automat Berlin GmbH, these very questions.

Detecon: Developers can work together with both telcos and hyperscalers who use the developers’ applications globally. What added value do telcos contribute to the cooperation?

Schönherr: The terminology itself used by telcos clearly illustrates the divide between the developer community and telcos. Developers are unfamiliar with terms such as hyperscalers and OTTs. The term “developer community” is equally obscure, and telcos would have to differentiate much more precisely in this respect. Nor is a developer familiar with the revenue sources of telcos or the telecommunications industry in general. For all these reasons, it is important to think of developers as if they were customers. And, of course, empathy – as always in a partnership – plays an important role.

Before a structured discussion about the added value that telcos can offer the developer community takes place, there must first be an understanding of what the developers need. Developer communities are clearly driven by content, so telcos must ask themselves these questions before a value proposition that is appropriate to the developer community can be developed:

  • How do developers obtain information and continue to learn? A distinction should be made between those who work on their own and those engaged by a company.
  • How do we reach the developers who are interesting for us?
  • What can we as a telecommunications company offer that is meaningful for developers?

So if we do not want to take the scattergun approach and address all developers on the market, we must first of all understand the motivation and background of potentially interesting developers before attempting to define what role telcos can play.

Can you give us an example of how a relationship with developers can be established?

I can do better than that and give you two: Twilio and Amazon Web Services (AWS). Twilio offers wholesale services obtained from telcos that they first enhance and then offer via APIs. Twilio has succeeded in developing an extraordinarily large market by offering a software stack of telcos’ products. A long list of SDKs and APIs enables AWS to serve the pertinent community as well, and it has turned itself into a data center service provider. These are two models that telcos can learn from. 

How do telcos benefit from the partnership?

They benefit from the future security. AWS and Twilio are fat cats in the telco domain. Twilio has managed to generate approximately one billion in revenues with text messaging services alone. And they have achieved that with only 1,500 employees worldwide. At the moment, telcos cannot compete with the data center services of AWS. They should fear for their existence, for their markets – and for a lack of success with their current products and services and the loss of competitiveness. If telcos realize too late the added value they can generate by working with software stacks, they will remain unattractive to developers in the future. Currently, the development approach of telcos is not practical for software companies – i.e., developers – so they should analyze their product lines and determine what parts can be adapted to make them attractive to developer communities. And then effective marketing actions must be initiated.

About: Marten Schönherr

Marten Schönherr is the founder and managing director of Automat Berlin GmbH, a specialist in software development in the field of programmable communications serving customers in Europe and North America. Marten Schönherr has had more than 20 years of experience in research and development in technical domains at Deutsche Telekom and other companies.

Are there any other arguments?

In the long term, telcos can also benefit from a learning curve when working with developers. Ideally, this learning curve results in innovative use cases and consequently in churn reduction. You must be careful in handling new sales potential. Generating new revenues takes a long time, and even then the sales potential is relatively small at first and rarely justifies the investment.

KPN, for example, is one of the first telecommunications companies to set up its own API shop. A fax API for business customers is available for purchase in the shop right now. The idea may not be very creative, but it is highly successful. The sales department plays an important role here and must also go through a learning curve. The potential for an API offer for start-ups was not recognized by the company’s own sales force as the business case was not profitable in the short term. Telcos today prefer to sell their text messaging service to Twilio because the business case for building a software stack does not generate revenues in the short term.

What must telcos do and what skills must they possess if they want to build successful, sustainable partnerships with external developer communities?

Telcos need to start by hiring people who understand developers, who are familiar with the sector, and who have an affinity for software development. For instance, API documentation must be clear and structured so that developers can quickly find what they need. Creating fancy, glossy documentation is of secondary importance. Telcos should instead start by preparing small and precise offerings rather than generically address the entire developer community. This can take the form of a small event with ten people. If the first event does not go well, you can learn from it and do better the next time around. Telcos should also never try to sell their product at such an event. A product should incorporate the feedback from these events and be developed step by step. The product should not be built until enough requirements have been cataloged and the relevance is clear to developers.

Telcos must develop new use cases that are pertinent for developers. The approach of the past – first building a product and then offering it – must be reversed. Telcos otherwise run the risk of developing something that developers do not need. Rudimentary ideas represent an adequate foundation to start trials on suitable channels such as meet-ups and conferences. The price alone is not enough to win over developers. Price AND quality are decisive. 

What role should telcos play in the future when it comes to cooperation in external ecosystems with developers and other partners?

Telcos should assume the role of partner/enabler if it can be ensured that both sides have an interest in the success of the partnership. This is the case during the joint development of use cases. But if it is clear from the outset what is needed, the telco plays more of a supplier role and the developer should be regarded as a customer. 

Are there positive and negative examples of such partnerships?

AWS initially gave out a lot of material free of charge to developers, hoping to lure them with these services. Developers first want to try out services and analyze the added value for themselves. Consequently, it is important, despite commercial interest, to offer the infrastructure free of charge at the beginning. Developers will not be able to pay hard cash for services until they earn money with the services. Telcos should define for themselves how much they would be willing to provide free of charge. 

There are several examples of telcos whose API efforts came too early and were actively thwarted internally because of fears of spam and cannibalization (text messaging and telephony APIs). The example of KPN is positive in the sense that the project has continued. On the other hand, it is not generating the expected revenues. A classic mistake has been made here. The API team would not have been able to obtain approval to launch the project if it had not promised sales targets that were totally unrealistic. This has a negative effect on the image of such projects internally.

Thank you for the interview!

The interview was conducted by