‍How TransferGo is revolutionizing developer experience with Port

Summary

‍TransferGo uses Port’s Internal Developer Portal to drive developer independence and provide managers with the tools to drive standards, initiatives and developer productivity.

TransferGo’s developer experience team was founded to improve how developers interact with the underlying platform at the company. One of the first challenges it needed to overcome was to reduce the labor associated with creating a single unified view of everything that exists in the platform, and how to make these views and insights accessible, meaningful and personalized for developers and managers. Without that, TransferGo’s team concluded, the developer experience would be compromised, resulting in lower developer productivity and satisfaction.

Setting the Scene 

TransferGo’s aim since being founded in 2012 has been to provide more accessible financial services to migrants, with cheaper and more efficient international money transfers. Today, the fintech company serves over six million customers in more than 160 countries worldwide. 

To serve such a vast number of customers and achieve its goals, the company takes developer experience (DevEx) seriously. About 18 months ago, TransferGo established a DevEx team as it recognized that this practice is central to their ability to deliver its product and drive productivity.

A core part of that team is Zbigniew Malcherczyk, a developer experience backend engineer for TransferGo, the first role of its kind at the company.

The Challenge

One of the first things Malcherczyk identified as a blocker to a great developer experience was the inability to provide developers and managers a “single pane of glass” that would let them see what’s going on and drive better software standards. Not only were details about service ownership difficult to find, there was little ability to tell what the AppSec status of the services are, unless considerable manual work was used. The reason for this is that AppSec status is dynamic, and the only way to keep it updated is to require multiple developers and team leads to update it, manually. This is true for almost any 3rd party tool as it relates to a software catalog. This affected developer productivity and satisfaction.

The core problem that Malcherczyk wanted to resolve is exemplified by the pre-existing practice of using a manually updated Excel sheet for everything from documenting software and microservices ownership to AppSec, driving engineering standards and providing views to different members of the TransferGo team. The knock-on effect of using the spreadsheet is a broken developer experience and an increase in developer and manager workload. 

Specifically, in its day to day work, the problem manifested itself as follows:

1. Using spreadsheets to manually record all information about microservices and other platform elements

The team attempted to use tags to indicate which team was the owner of a particular asset or initiative. But that too was manual, making it difficult to create a single source of truth; the lack of standardization meant this didn’t work as intended to identify resources, assets or owners, and this ultimately increased the cognitive load on developers, while having an adverse impact on experience. 

It is difficult to maintain and effectively use a spreadsheet as a software catalog. A spreadsheet was used to track software ownership. By their very nature, manual records are  not scalable, requiring developers to manually check external services (such as AppSec tools for vulnerabilities, issues etc) for updates and then to manually update the spreadsheet. Without up-to-date data and context, it is almost impossible to answer critical questions or drive ownership and accountability, impacting developer experience, agility and engineering standards. It also siloes data. 

2. Driving AppSec compliance using manual work

TransferGo’s AppSec requirements were growing and it wanted to support developers as owners of AppSec issues, but with the spreadsheets there wasn’t enough visibility to support this and to tie AppSec issues such as vulnerabilities to microservices. The microservices context helps developers understand the severity of a vulnerability and prioritise remediation accordingly.

“An example is the difficulty of using a spreadsheet is when monitoring engineering standards compliance; It’s very difficult to maintain the number manually on Excel, because they change frequently and you would have to spend a significant time each week looking into each service, and this increases the chance of errors,” said Malcherczyk. 

3. Tracking initiatives 

Another area that the team had been seeking improvement in was defining, communicating and tracking initiatives. 

For example, each year TransferGo has a PHP version upgrade initiative, and this has always been a difficult initiative that was accomplished using the Jira and Slack, which also created significant communication challenges. This presented the same issues as the Excel-based software catalog; more manual work and a higher chance of errors, both detrimental to developer productivity and experience.

Malcherczyk explained the tediousness of working on the initiative without a developer portal:

•  Look at 30 plus services 
•  Fetch the information about the PHP version
•  Put it in a spreadsheet (or somewhere that it can be visible for every engineer or tech manager)
•  Create the Jira tickets for each of the team who all have their own project
•  Communicate required workload to each manager and tech lead
•  Associate the service with the team and track all of the changes

Malcherzyk was seeking a way in which they could easily track the initiative from the beginning, reducing the manual effort required by developers and allowing managers to quickly see how it was progressing. 

His team also wanted to ensure compliance with organizational standards via scorecards - a way to measure and track the health and progress of each service and application within the software catalog. Unlike one-off initiatives, this is an ongoing task that’s almost impossible to do manually.

4. Visualizations

‍Malcherczyk wanted the ability to customize views in the catalog for all of the different teams - engineers, developer experience personnel, managers, directors, and the SRE team - as they all require different information. 

When asked by Port’s team, what he would want to show different engineering manager roles, he listed these needs, by persona. He uses the “jobs to be done” framework, as in “As [role] I would like to [do something]”.

The Internal Developer Portal Solution

Considering the challenges above, Malcherczyk suggested it was time for TransferGo to choose and implement an Internal Developer Portal.
After identifying a number of potential solutions, TransferGo selected Port based on Malcherczyk’s work.

“We wanted flexibility; Port has high customizability, we could build our Internal Developer Portal based on our needs, and we would get long-term value with Port,” he said. They used this flexibility in defining scorecards according to the engineering quality metrics that mattered to TransferGo.

With another vendor, Malcherczyk explained that TransferGo would have to comply with the vendor’s definition of engineering standards, whereas with Port they could build their own data model and there would be no need to make organizational changes to fit with the alternative vendor’s standard. 

“You’re able to represent your organization in Port and then you can scorecard and automate all the information that is already there. You bring your organization to Port and you’re not trying to change your organization to the software, which is the difference,” Malcherczyk said.

Port’s software catalog is a central metadata store for everything application-related. 

It can help the company answer critical questions (eg. What is the version of the checkout service in staging vs production?), it drives ownership and accountability by syncing with TransferGo’s identity provider to reflect software ownership from the team perspective, and it offers a ‘single pane of glass’ into the product’s services and applications. 

With everything in one place, the team can easily communicate quality, cost and AppSec standards/posture and drive change. They can define their own standards for quality, maturity and readiness. In addition, they can use Port to communicate initiatives and track them seamlessly by developer, team and service, reducing the previous manual load on developers. 

As it is an open data model, Malcherczyk can see Port as a long-term partner with numerous use cases for the portal.

He explained that Port can even help the company to comply with audits such as PCI Compliance through an access management  use case. 

“Engineers need to request access to certain tools through the Jira ticketing system and it requires manager approval. But we don’t want every engineer to have admin access to every tool, as then you would have to migrate the tokens and the API keys every time someone leaves the company. With Port's approvals you are able to automate the approvals process,” he said.

Dashboard customization was also seen as a strength of Port’s since it supports the definition of different views for different personas, as defined by Malcherczyk.

“I haven’t seen anything this customisable before; Port provides us dedicated views per team, role or user. You can filter, define visible properties or decide on grouping, which may change the standard list to a totally different view - like a Bird’s Eye view,” he said.

Each team and persona therefore has their own dashboards, homepages and set of permissions. 

Last but not least, RBAC was also a selection criteria. With Port’s comprehensive role-based access control (RBAC) model, TransferGo can select two approaches of working with users and permissions. The first is the built-in ability to create users with specific roles and teams and then assign users to teams. The second is using Blueprints to define its own rules and properties and use them as the source of RBAC. 

“This is one of the most powerful RBACs possible because we can actually bring our own rules and we have different rules for directors, engineers and managers, meaning all of them require different permissions,” Malcherczyk said.

What’s next

Port is a key part of TransferGo’s efforts to improve DevEx. This is just the beginning.

To understand where to go next, the team also runs a quarterly survey based on the company’s forthcoming development plans. The idea is to get a better understanding of the developers’ pain points and to prioritize actions and goals based on these issues. The responses are broken down into roles, so that the DevEx team can better understand how the issues are impacting different teams. The findings will help Malcherzyk to plan the development of the portal from now on.

The survey also supports the team’s aim to look for new opportunities, tools and processes that can stimulate developer productivity, encourage better collaboration and reduce cognitive load. His overarching goal: to revolutionize developer experience. 

By instilling a dedicated developer experience team, regularly seeking feedback from all levels of the organization and using an Internal Developer Portal that can integrate data sources, automate workflows, set standards and track initiatives, TransferGo and Malcherczyk are well on their way to achieving their goals.