Mihaela Popa
12 Nov 2021
•
5 min read
Founded in 2019, Commsor is building software for community professionals, reiterating once again that a thriving community is a company's most valuable asset.
With a fully distributed team, they have recently closed a $16M Series A to continue building for a community-led future.
We asked Mac Reddin, Commsor’s Co-founder and CEO and their head of engineering, BJ Neilsen, about Commsor’s use of Clojure, the advantages and trade offs it brought to the team, as well as what they are currently working on, their biggest achievements and much more.
Before we dive in, don’t forget to sign up and subscribe to our newsletter to get personalised content and job opportunities straight into your inbox!
Commsor provides a community operating system for your company. We integrate with all the tools you already use, tying your community together and enabling you to unlock insights, measure impact, and build a Community-Led company.
We're accomplishing the above strategy by building integrations (from slack, github, twitter, etc) to retrieve community member information and activities, then providing insights into those activities by doing entity resolution across your various community applications and activity analytics. We're also building tools for interacting with the community through workflows, content scheduling, etc.
One of our core user stories might go something like this: As a community manager at BigCo, I want to see which cohort in my community is engaging most often across all channels, so that I can elevate their message more effectively.
We use Clojure for our backend app servers and ClojureScript with React for our frontend. We use JUXT Edge as our backend framework, and we deploy via AWS Elastic Beanstalk. We use PostgreSQL for our primary database. Our frontend compilation is currently handled by Figwheel Main. Our CI/CD is handled by Circle.
Our engineering team has many years of experience with Clojure, it's an ecosystem we know well and find extremely productive. We've found that Clojure allows us to iterate very quickly and focus on the problem we're trying to solve rather than battling the language due to lack of features. Lisp's incredible power combined with Clojure's JVM support and fantastic standard library have made Clojure our favorite language.
There is a tendency in the community to build libraries in the Unix philosophy of "do one thing well", and often you have to figure out how to glue different pieces together; there aren't a lot of 'batteries included' ways of doing things. This adds some conceptual overhead sometimes, but it also forces you to develop a greater awareness of how your tools work and make sure you are assembling a solution which is appropriate for your context.
We had a problem with Datadog where we couldn't get automatic instrumentation of our functions to work, because of some peculiarities in how the JVM bytecode is generated. So it's important to do your homework on all components of your stack and make sure they're going to work properly if you're using a more niche language.
Arriving at a ClojureScript+React set up that we are happy with has taken a while: we moved from custom interop through a couple of different wrapper libraries before we finally settled on Helix, with a little custom magic sprinkled into our createElement macro. In other languages you might come across "the one big lib" which is the standard for how a certain thing is done, whereas in Clojure there are usually a handful of different libs by different authors. The advantage is that collectively, the community is really good at exploring the problem space and building different solutions with different trade-offs. But the disadvantage is that you have to take more time to evaluate different solutions and make sure you're picking the right tool for the job.
With Clojure specifically, the talent pool is a lot smaller: the usual story we hear from candidates is that they've been working in industry for a few years on Java/Ruby/JS/..., eventually they found Clojure and played with it, fell in love, and then they moved into the Clojure job market. The smaller talent pool has its pros and cons. One the one hand, we don't have to sift hundreds of CVs every week because the niche-ness of the language has done the sift for us, and almost every candidate we talk to is of a high caliber. On the other hand, we don't get as many applicants as we would like sometimes, and it takes us longer to find talent and bring people in.
Our focus over the next two quarters is to increase performance, throughput, and load capacity in our system. We've built dozens of integrations for pulling community member info and activities, now we need to improve data ingestion and processing pipelines for better analytics and query performance. We're also integrating a workflow engine so that customers can automate interactions based on a broad range of community member activity.
It's hard to say because there is so much happening all throughout the company! We've launched and grown C-School, our training program for Community Managers and Leaders; We launched our NFT project, the Commsaurs; we've acquired two companies, Meetsy and Port, which has broadened our product offering and brought some incredible talent in to the team; and we've scaled from a team of ~6 people to now over 40!
We love talking to people who are passionate about building high quality software, regardless of preferred language or platform. We recognize that interviewing can be incredibly time consuming and take up lots of energy, so we want to be efficient and respectful of the candidate's time.
Our candidate pipeline is similar to other companies that usually starts with a brief screening call with our Head of Engineering, then proceeds to conversations with engineers and leads, then proceeds to a pairing session and code review with a team engineer, and finally to the offer stage with the Head of Engineering and Director of People.
We are a growing startup which has found a market desperate for software solutions to community management problems. We have fantastic backing from investment partners, and our team is passionate about building quality software with long-term outcomes for our customers. Our team is distributed around the world from San Francisco to Warsaw, New Delhi to Cape Town. We value deep async work paired with consistent, effective, and thoughtful communication.
Engineers at Commsor have high levels of autonomy and accountability. We expect engineers to collaborate with empathy and patience. We prefer an agile approach to software development where implementations are as small as possible while still proving customer value, iterating carefully to produce reliable, accurate solutions to customer problems. We value data-driven decisions and consensus-seeking conversations.
If any of the above seems exciting to you and you’re interested in joining the team at Commsor they are currently hiring so make sure to check out their open roles!
Thanks for reading and happy coding, Mihaela x
Ground Floor, Verse Building, 18 Brunswick Place, London, N1 6DZ
108 E 16th Street, New York, NY 10003
Join over 111,000 others and get access to exclusive content, job opportunities and more!