We place a high degree of trust in our team members.
As a small startup, everyone at Grouparoo is involved in the entire life-cycle of a feature – from ideation and prioritization, through development, release, monitoring, and bug-fixing. You’ll have the latitude to choose the best tools and frameworks for the job and not be locked into legacy tools or decisions.
We are a team of generalists switching from topic to topic and are looking for engineers who are excited to explore the whole stack (frontend, backend, devops, etc.) rather than experts who specialize in just one part. This way, everyone can own the whole feature, not just the UI or API layer. We place a greater value on holistic knowledge of the architecture and the ability to learn rather than existing expertise in any single part of the stack.
Safe Environment to Fail
We have the freedom to move quickly, make mistakes, and learn from them.
There is a lot of stuff to build. It’s exciting, but some mistakes are inevitable. We strive to create a safe space that’s open to failure. We learn from our mistakes openly and support each other in the process. To foster a safe learning environment, we try to document everything so we and future team members can build off of what we’ve learned (see Open Communication).
For developers, we prioritize building tools along the way to help reduce that risk, like CI/CD, linters, and release automation to help us ensure that a small number of people can be responsible for a large codebase. We do weekly releases to quickly fix bugs that crop up, and invest time to improve the upgrade process for our customers. We pair regularly to share new work and to collaboratively solve tough problems.
Open Source Contributor
Grouparoo is building open source tools, so almost everything we do is in the open.
We know that open-source is the best channel for developers to adopt new tools, and we want to be as transparent with our customers as we can. To that end, we embrace open source tools and workflows like Git, GitHub, and Pull Requests in our everyday work. Your work will be directly attributable back to you and users can directly converse with you as a result. For example, when Evan rolled out the Postgres plugin, he had a great discussion with a customer on the pull request about some of the nuances around Postgres SSL and authentication. We were able to build a more robust product that met the customer’s needs.
We encourage our users to contribute and communicate with us using these same tools. Our customer support process is via GitHub Issues, our Roadmap is public, and we even modify our employee handbook with pull requests. Grouparoo is “all-in” on open source.
Engages with Community
You’ll interact directly with users and decide what we build to best serve our community.
Building a successful open source project is more than just writing code – it’s also about building an engaged and satisfied community. As a Founding Engineer at Grouparoo, not only will you be writing code, but you’ll also share your work with the community and determine what to build next. Everyone at Grouparoo interacts with our users and helps build our community. takes many forms. Whether it’s via blogging, conference talks, solving customer issues, or supporting their deployments, you’ll have a hand in crafting our community tools and platforms as we grow.
Grouparoo is building data tools made by and for engineers.
We spend a lot of time thinking about things like the UX of CLI interfaces, how to install and distribute software, and how painful upgrading to the next version might be. Building our roadmap is a collaborative exercise between all members of the company and our users – who are mostly other engineers.
We have early customers who help us drive our roadmap at all levels from issues to feature requests. For example, they let us know which connections they need and give us feedback about our deployment strategies. In the future, we'll allow users to upvote and react to issues as a way to inform our decision-making.
Almost everything we do is shared with read and comment access.
We believe the best way to run a remote company is to work asynchronously in the open. We carry the ‘work in the open’ mindset from our codebase to every part of the company. Almost everything we do, from documents to digital whiteboards, is shared with the rest of the company. To better enable asynchronous work, we share our plans and documents early, ask for feedback often, and we write a lot. The practice of documented sharing helps create safety and trust in a distributed team, along with a culture of enablement.
We use tools like Slack, Google Meet, and Tuple to communicate synchronously when needed, and otherwise rely on cloud-native tools like Google Docs and GitHub.
Flexible Work Arrangements
We have core hours, but the rest of the day is up to you!
We try to strike a balance between coordination and flexibility. As a distributed team, we want to create a comfortable environment for our team members in different time zones and with varying obligations outside of work. Our core hours are from 9am to 1pm PDT, which allows us time to meet synchronously and pair as needed, but how you schedule the rest of the day is up to you – we have families, friends, and hobbies, too! Andy likes to go for 6am runs and Brian helps his kids attend school remotely. We also want to help you build a space you can be productive in, so we chip in with a monthly internet stipend and a $1,000 home-office budget to get you set up.
Bonded by Love for Product
Grouparoo was founded by people who have all experienced the pain of not getting data syncing right.
At previous companies, we’ve been unable to meet objectives and created bottlenecks for our marketing and ops teams. We have experienced both the organizational and technical hurdles of not getting data syncing right. As technical founders, we want to make sure that no engineer ever has to worry about vendor rate limits, obtuse APIs, or accidentally sharing PII with the wrong vendor again. We hope everyone who joins Grouparoo can share our goal of turning the slow and tedious task of data management into something that ‘just works’.