OmbuLabs Blog

As an agency, our business model revolves around time. Our client activities rely on a dedicated number of hours per week worked on a project, and our internal activities follow the same pattern. As such, time tracking is a vital part of our work. Ensuring time is tracked correctly, and time entries meet a minimum quality standard, allows us to be more data-driven in our decisions, provide detailed invoices to our clients and better manage our own projects and initiatives.

Despite being a core activity, we had been having several issues with it not being completed or not being completed properly. A report we ran at the end of 2022 showed our time tracking issues were actually quite severe. We lost approximately one million dollars in 2022 due to time tracking issues that led to decisions made on poor data. It was imperative that we solved the problem.

To help with this issue, we created an evolution of our Pecas project. We turned Pecas into a machine learning powered application capable of alerting users of issues in their time entries. In this article, we’ll talk though the business case behind it and expected benefits to our company.

At OmbuLabs, we love remote work. While other companies are asking employees to come back into the office, we are continuing to lean into the remote-first work culture that we had even before the pandemic. In this article, I will discuss the reasons why remote work is essential to the culture of our company. I will then outline how we create a culture that is both remote-friendly and productive.

Just before the world shut down in 2020, the team at OmbuLabs participated in an in-person retreat in Punta Cana. It was a wonderful experience, and the team was eager to have another retreat in 2021. We even began planning one, but with the safety of team members at risk because of the pandemic and the difficulty of traveling it soon became obvious that an in-person retreat would not be possible. Therefore we turned our attention to having the retreat virtually.

This ended up being a very successful event, and we wanted to share the experience and strategies that we used to plan and execute this retreat which took place virtually over four days towards the end of 2021.

I joined OmbuLabs as a Senior Software Engineer on February 11, which was a Friday-more on this later! Tomorrow I will have completed 2 weeks here. So if you want to find out about the onboarding process at OmbuLabs, read on.

At OmbuLabs the first step in the interview process for any of our open positions is the cultural fit interview. This interview will tell us a few things about the candidates. It should let us know if they have the kind of experience that would match well with the open job, it also shows us if the candidate would settle in well with the values of the team, and it tells us if we think we should offer a second interview.

OmbuLabs is a fully remote company based out of Philadelphia with team members in many countries. Currently we are growing pretty steadily, and we thought it would be a good idea to let prospective employees know what it would be like to work at OmbuLabs.

This article is based on questions we often get during interviews, so we hope it helps if you are thinking about applying to OmbuLabs. You can learn more about the recruitment process here.

One of the main goals we set for 2021 is to become more efficient as an agile team. And one of the challenges we addressed was how to minimize the decision-making bottleneck. To confront that we decided to take some actions that I’m listing below.

At OmbuLabs our goal is always to smooth processes, and make work easier. Isn’t that what software engineering is really all about in the first place?

When we are getting ready to do a project or to make a proposal one of the questions that we are always asked by clients is “how long will it take”? To come up with an estimate on timing we like to use a system of points and blind estimates by multiple team members to find an average of how complex the project will be. We can then use this information, together with our database of delivered projects, to estimate how long the project will take.

To accomplish this, and make the process smoother we built a tool called Points and now we have moved it to open source in case it can be of use to any other teams out there!

As a software consulting company, we bill for the time we work on client projects. So it is vital for us to keep track of the time we put into every task. We’ve had some trouble over the years with our time tracking, and sometimes that led us to work more time than what we finally billed for. We would like to share some of the experience we have collected over the years and the tools that we currently use.

At OmbuLabs we use Tettra to power our knowledge base. As a remote, distributed team it is very important to us to have our content structured and organized. We follow some good practices to keep it organized and up to date, which we describe here, and we use Tettra to keep our knowledge organized and integrated with the tools we use on a daily basis.

As a distributed, remote team we use different tools to communicate at OmbuLabs, like Slack and Zoom. Those are great for live communication. But every company has information that needs to be kept and stored somewhere. In our case, we started off using the GitHub Wiki and Google Docs. However, documentation and policies need to be maintained, updated and checked regularly. And having information scattered in different tools, formats and accounts became a hassle.

That’s where a knowledge base comes in. At OmbuLabs we use Tettra and we will share our experience in a different article. But regardless of what tool you choose, here are some practices that will help you keep your knowledge base organized and updated.

The discussion around the use of problematic words / terms in technology isn’t a new one. This issue can be traced back to, at least, 2003 when a Los Angeles county worker filed a complaint with the city’s Office of Affirmative Action Compliance after seeing “master” and “slave” in computer equipment labels.

This issue has resurfaced with recent events and, at OmbuLabs, we believe it is important to take it seriously. It is past time to remove this metaphor from our codebase and review some of the terminology we use. We have started taking the necessary steps to rename “master” branches to “main”, as well as (and perhaps more importantly) remove any reference to the term “slave” and replace “whitelist / blacklist” with “allowlist / blocklist”. Our team is actively working on that.

But we understand that is not enough. This is not an action that will solve racism by itself. It’s part of a larger commitment. In this article, I’ll explain the context and motivation for this change and how it fits with our core values and long term vision as a company.

As a remote team, we work and communicate asynchronously a lot of the time. Additionally, as a software agency, we work not only on client projects but also internal projects related to various aspects of the company. This means we will have stories and pull requests opened accross different internal projects at all times and it is important that everyone is on the same page when it comes to what needs their attention and what the next steps are.

We have shared more information on how we use Pivotal Tracker here. We also like to use GitHub to its full potential. Therefore, we needed a standardized workflow that would take into account how we use both these tools and ensure everybody on the team knows what is going on by looking at a Pivotal Tracker board or a list of open Pull Requests.

In this article, I will walk you through the workflow we created for our team. You can find a flowchart representation of the workflow here.

Becoming the Apprentice, and then Junior Developer at OmbuLabs was both exciting and nerve racking. Learning a new company can be challenging, especially when the skills are new and the work is remote.

Fortunately OmbuLabs made the journey a smooth and easy process. Here are some of the things that have been working.

Remote work is a growing reality. In the 21st century, we have distributed companies that work 100% remotely, with team members scattered around the world.

While remote work has its benefits - diversity in background and experiences, access to an immense talent pool, cut down office costs to name a few - it also brings its challenges. And the biggest one is communication.

There are several pieces of software that aim to facilitate communication in a remote work environment. At OmbuLabs, we use Slack for our day-to-day conversations and Zoom for our calls. However, as a remote team, we don’t get to meet our teammates face to face. We don’t have “water cooler” chats or as many opportunities for casual chats as an office environment.

So how can we bring our team closer together? How can we build that team spirit that comes from seeing everyone and talking about our casual, social lives? Well, last month we had a team retreat. And it was great.

At OmbuLabs, we strongly believe in continuous improvement.

As a Scrum team, before starting a sprint we estimate the complexity of the stories using the Fibonacci scale. But how do we become better at estimating stories? How do we know we’re evolving as a team?

In this article I outline the process we are following to become better estimators.

When a new team member comes onboard, there are several tools and resources they need to access, as well as processes, practices and guidelines they need to be aware of. There is also workflow and company culture information you want to communicate. After all, each company has its unique features and you want new team members to be comfortable with the existing team.

For remote teams, this process can be very challenging. Thankfully, if you use Slack, you can use their Workflows feature to easily onboard new team members, making the process actionable and easy to follow.

In this article I’ll describe how I used Slack Workflows to make the onboarding process here at OmbuLabs quick and easy.

Different clients bring different projects, perspectives, workflows, and experiences, as well as different challenges. Before starting a project, one of those challenges is to define who will be the Product Owner.

Ideally, you would be able to assign the role internally or to the client based solely on the characteristics of the project. However, that’s not always the case. It might just be that the client insists on being the Product Owner or that you are a small team and can’t really assign the role internally. Whatever the reason, you might end up in a situation where your client isn’t really a good Product Owner.

Here I’ll share some strategies we implement to help our clients become better Product Owners and ensure the best experience for them and for our team.

We have been a fully remote company for a year and a half now. Making the transition to being fully remote can be challenging for any team. During the past year and a half we have worked on making sure that our team is as productive, communicative and social as it was when we had a traditional office space. Here are some tips that we have found to be useful for remote teams:

Pull Requests let developers tell other team members about changes they’ve made to a project repository. Once a pull request is created, team members can review the set of changes, discuss potential modifications and even push follow-up commits before the changes are merged into the repository. Therefore, it is important to make sure that your pull requests are easily understandable to the reviewers.

Sprint Retrospectives are a crucial part of our project management strategy at OmbuLabs. Because we are a remote and international team of software developers, we miss out on the “water-cooler” conversations and small talk that would normally occur between employees in a typical office environment.

At OmbuLabs, we like to split our time between working on our own products, open source and client projects.

Our own products include everything from OmbuShop, an e-commerce platform, to FastRuby.io, a Ruby on Rails upgrade service. In terms of open source, we recently created Audit Tool and are constantly searching for more projects to contribute to. We also work on a variety of interesting client projects, and with our current team size, like to take on two to three of them at a time.

As an Account Manager, it can get hectic trying to manage all of this. Google Calendar can be a serious help.

At OmbuLabs, we have a number of tools that help us to keep organized, write better code and communicate more effectively with our clients.

When starting a new software development project with a client, it is important to get started on the right foot. The way you communicate with a client at the beginning of a project can set the tone for how communication will be throughout the project.

Therefore, at OmbuLabs, we believe it is crucial to start off every new project with a Kickoff Call, where we can take time to get to know the client’s team and speak in depth about their goals and priorities for the project. We like to discuss the following list of topics with clients during our calls:

We like to use GitHub to its full potential at OmbuLabs, so any tool we add to the toolset needs to integrate nicely with it. As a growing agency working in larger and increasingly more complex projects, we need a project management tool that allows us to keep track of our work and plan accordingly. For this, we use Pivotal Tracker.

There are many things that are easier with Pivotal Tracker, as long as you are using it the right way. Some of its features are very useful for agile teams like ours. This is how we like to use it to ship value with every sprint and keep track of our team velocity.

There are a few agile practices that I really love. Pair programming is one of them.

We try to do it as much as possible at OmbuLabs. We usually keep the sessions under two hours and try to follow a regular schedule.

When we find ourselves blocked by a code problem, we use our daily scrum to coordinate a pairing session. It’s quite a step up from rubberducking or using a cardboard programmer to find a solution to a problem.

The Joys

As a Senior developer, I find that pairing sessions are great for coaching Junior developers. I enjoy teaching them about best practices, design patterns, frameworks, languages, code style, XP, and TDD.

From the point of view of a Junior developer, I believe it’s a great opportunity to learn from someone who “has been there before”. When you program with someone with more experience, you will often learn about design patterns, elegant object-oriented solutions, tips and tricks.

This is our process to hire new full-time developers at OmbuLabs. It’s a process that we have been improving ever since we started our operations. It’s very important for us to hire “A” players.

In this article we will focus on how we evaluate new developers, but parts of the process can be customized for other positions as well.