Continued from page 1.
When we need to migrate from one system to another, or when developers introduce a feature that requires us to adapt past data, we must move carefully to coordinate all the tasks involved. In a Google Doc, we'll all plan out which part of the migration each team member will take.
Here is an example of how we might layout tasks in the document using our initials to show who it's assigned to:
[GF] alter the table adding a new column (query #1)
[MC] stop system queues
[GF] populate the new column for the past (query #2)
[AV] merge API branch /xxx-yyy-zzz and deploy it
[MC] restart system queues
[AR] run tests over API
For complicated system migrations that require cross-level interaction, we usually create a custom Slack channel to coordinate our actions in real time. But generally complex tasks like these can take hours, or even days, so using Google Docs is a great way to decouple dependencies and keep track of the status of the migration, which would clutter our Trello boards with lots of small cards.
When we need to discuss a very specific technological issue that needs solving, we also make use of GitLab discussions.
You can leave resolvable comments throughout GitLab on issues, merge requests, etc. The comments support markdown and quick actions stop you from forgetting to address any feedback or issues. This approach helps us keep track of progress during planning and code reviews. Also, like in Google Docs, the team has worked out everything, you can simply resolve the comments.
Building the Rebrandly API requires modeling Rebrandly's world in such a way that everything is coherent and abstract enough to build more in the future. We want to guarantee long-term backward-compatibility and great performances at any scale. We have strict processes and naming conventions to keep as many entries as possible self-describing. A good API has perfect naming, which does not raise questions. We measure our success in this by the number of integrations built without contact with our tech support.
We use ReadMe.io to present our API online. Its lets us keep our API constantly updated and allows us to collaborate with other developers outside of our team.
Our Developer Hub is public and you can even test our API endpoints directly in your browser. This openness is important for our business, because we want third-party developers to use our API and integrate our branded link creation app with other services that are useful to our customers, like social media management or CRM tools. We figure the easier it is for them to do this, the more it will happen.
Our documentation on ReadMe.io makes this easy because, as well as including all the technical aspects of our API, the Getting Started section gives developers a walkthrough for setting up a first working script.
Figure 5. Examples we include in our documentation on Readme.io.
Last year, we had over 3,000 developers use our API key, and so far we've had lots of positive feedback. If third-party developers need anything, they can reach support channels easily. They can also suggest edits to the documentation when it's unclear or write comments in the Discussions section of ReadMe, and we will receive an email alert.
Beyond building and maintaining our API, we use Zeplin to collaborate with our lead UI designer. Together we organise all the design work, from early stage work-in-progress mockups to production-ready specs. Almost the entire team can access the projects - designers, devs, marketing and, of course, our founder - so we have a well organized structure to help separate the bulk of work.
We use separators to identify each part of the project and, within it, you can find lots of screens describing interactions and rules for the app. For collaboration within Zeplin, we also frequently use its Comments function. We quickly tag another teammate in a specific part of the page to draw their attention to any suggestions, doubts, or general notes.
Figure 6. Zeplin is the key technology for the company to collaborate with designers.
When we log in, we can see our dashboard or view the style guide in the second tab. The style guide determines fonts and colors and keeps everything in sync. Instead of naming colours and changing them for every update, Zeplin exports code snippets out of designs and does the repetitive work for us.
It also makes design handover quite straightforward and streamlines implementation for our team.
Developments in collaboration and communications technology have made it easier for us to work together without needing to be in the same room. But as well as using great tools, it's also important to have solid procedures around them, so they can be used effectively and optimized for communications.
For example, our team uses Skype to message another team member when we're in need of an immediate response, especially because frequently these quick messages need to turn into quick calls. While we use email for less immediate communications, the entire team knows an email doesn't have to be addressed straight away and often the message will concern a task that will take some time to complete.
The fact that our team members are living in various countries makes us diverse and gives us an edge. It's something we are quite proud of and it makes sense as our tool is used around the world too.
Everyone on our team is encouraged to give feedback and highlight when a tool or procedure isn't working. Based on everyone's input, we periodically revise the tools we use. Though we're not all together in an office environment, having great collaboration tools allows us to easily ask for guidance or provide help to each other. This means nobody gets stressed or stuck spending too much time on one task. It also allows us all to work to our strengths and results in the fast completion of projects.