Request access
.png)
Enhancing Developer Autonomy and Efficiency with Rely
Software development is a complex task requiring a diverse set of skills and knowledge. You would probably think that this would mean having very large teams but that has proven to be counter productive. Instead of large teams with varied skillsets that cover different domains, it is common to see what is know in the industry as “two pizza teams”. Two pizza teams are multi-disciplinary teams, usually sized between 5 to 8 people and they are domain/outcome focused rather than activity focused (e.g. databases, testing, operations, …).
As a result, it's common to find software development teams composed of developers with varying skills. These diverse teams can more effectively process requirements from Product Owners and deliver features to customers.
However, this approach can lead to the creation of knowledge silos within companies, which can negatively impact overall productivity.
Avoiding “tribal knowledge”
Knowledge silos are very common and they happen in all industries and practices, software development is not an exception. So what are knowledge silos?
Knowledge silos, or "tribal knowledge," occur when a small number of people, potentially even one person, possess all the knowledge about a specific topic or practice. This may encompass knowledge of a particular technology, software implementation, or an essential business process.
These, naturally, pose a risk to the overall business for several reasons.
The employee is leaving, now what? When a key component of your organization's knowledge leaves with a former employee, the risk of business impact can increase due to the lack of maintenance for that component. How should you handle this situation?
Developers dedicate significant time to meetings with other teams interested in using this component. Developers enjoy developing new features and providing value to customers. However, to do this effectively, they need to concentrate on their primary task - writing code. Spending excessive time in internal meetings explaining software usage can detract from their productivity and job satisfaction.
“Context switching is killing productivity” they say. Software development requires intense focus and concentration, necessitating developers to avoid distractions. However, they also need to stay connected with other teams, ensuring they don't hinder progress. As a result, they often find themselves in repetitive meetings discussing the same topic.
Furthermore, the broad range of modern software development tools and teams’ freedom of choice often leads to teams within the same organization using different tools for the same purpose. This diversity can make it challenging for individuals to know where to locate and seek information.
Consider the example of a person in your organization searching for information on a specific service or component. The following is likely the workflow they would use.
This could be a Product Manager from a different team trying to understand how to integrate or use your service. It could also be a new hire who needs to familiarize themselves with the service they will be working on.
Clearly, all these steps are time-consuming and impact not only the person seeking information, but also the individuals who possess the knowledge they need.
Definitely not the most efficient or satisfying process in the world.
What can we do then?
From my perspective, this is a two-step process that can be easily implemented by software developers and SRE/Platform engineers. This is applicable even if the organization does not have a team specifically building platforms or focused on improving the developer experience.
1) Documentation as code.
Many developers may not be thrilled at the prospect of writing documentation for their services. However, seasoned teams understand its importance. Without clear and effective documentation, they may face constant interruptions, negatively affecting their productivity and satisfaction.
In software development, the principle of implementing everything in code should extend to documentation as well. If the documentation resides in the same repository as the code, it becomes much easier to locate.
2) Making the information easily accessible.
Modern distributed organizations often face two distinct problems: lack of information due to the non-prioritization of best practices for operational excellence, or an abundance of data sources where information can be scattered.
While both issues can be partly addressed by the previous step - Documentation as code - this doesn't solve the issue of accessibility. If your documentation is in the code repository, you still need to locate it. Additionally, finding information across different services remains a challenge.
Therefore, it's necessary to centralize all this information in one location known to everyone in the organization.
And is documentation the only thing people might be seeking? What about the maturity of your CI/CD process? Or your testing capabilities? Or the frequency of service incidents that impact your customers?
Rely’s approach to solving this problem
Rely is an internal developer portal designed to enhance developer autonomy and visibility throughout the software delivery lifecycle.
Rely allows you to import service information from various data sources. These sources cover different stages of your application lifecycle, including Project Management (such as Jira), Code Repository and CI/CD (GitHub, Gitlab, ArgoCD), Infrastructure Hosting (AWS, Azure, GCP or Kubernetes), Observability (Datadog, New Relic, or Grafana Cloud), and Incident Management (PagerDuty).
.png)
Data ingestion is accomplished using built-in plugins or integrations. These allow you to connect to your own data sources without having to write a single line of code.
These integrations will automatically and periodically ingest your data into the software catalog. From there, you can customize your experience by selecting relevant entities and adjusting their visibility. This will display or hide the entities in the left sidebar.
Upon selecting an entity, a dashboard will appear with the available data for that entity type. Here, you can choose which columns to display, hide, or arrange as per your preference.
But why stop there?
If you aim to provide a seamless experience to your users, it's best to avoid having them switch between multiple tabs based on the resources they need to interact with. Let's explore how we can achieve this.
Blueprints and the data model
By default, Rely provides a set of blueprints for built-in entity types, such as Service, Domain, Deployment, etc. These are part of a data model representing the dependency relations between them. This is where the fun begins!
A typical user journey in Internal Developer Portals (IDPs) begins with the service entity, where users often start their search for information. They then review the basic information about that service and move to its dependencies.
Keeping this in mind, you can easily create dependencies between entities, such as a Service and a GitHub repository, using the Data model page under Portal Builder.
To do this, open the service blueprint, and in the relations section, click the '+' button to add a new dependency. Select GitHub repository and map the properties you want to display on the service page, such as the repo location and readme.
After making changes to a blueprint, the data model's visual representation will update to reflect the new dependencies.
When you create a service, the new properties (repo location and readme) will appear on the screen. Upon selecting a GitHub repository, these properties will automatically populate.
Focus on what matters the most
Being an expert on a topic and providing reliable information to others is rewarding, but it doesn't scale if you are the only one having that knowledge. More importantly, it may prevent you and your team from focusing on more relevant tasks.
Using an Internal Developer Portal can help you scale by providing access to information to others in a self-service way.
Demonstrate your expertise in a more effective and intelligent manner.
See related articles
Why does improving Engineering Performance feel broken?
.png)
Top Backstage alternatives
.png)
Internal Developer Portals: Autonomy, Governance and the Golden Path
