How we work at Simplero
We have a big visions for our product.
We want Simplero to be the undisputedly best place for someone who's really good at teaching something, at transforming people's lives through their education, to go build their business. We take care of the technology, offering them all the tools they need under one roof, with the best customer service they've ever experienced, so they can focus on attracting and serving their customers and building their business.
In short, Simplero is the operating system for your business.
Simplero's role in our customers' lives is to be a Freedom Machine™️. It helps them live where they want, work how they want, when they want, with the people the want to work with, and make the amount of money they want. That's why our work matters.
We have things on our roadmap that go from blurry visions for some further out future, down to the things we're working on this week.
We evaluate our current priorities on a monthly basis to check that it aligns with our customers' wishes and needs and with our strategic needs.
Based on that, we come up with what we're working on this week.
There's a lot of leeway for you to influence the roadmap. We're driven by good ideas and solid arguments. If you make a strong case, chances are we'll decide to go with your idea.
All this boils down to a Github Project kanban board where we organize the work according to "To Define", "To Do", "In Progress", "To Review", "To Deploy", and finally "Deployed".
Process and Communication
We use a light-weight adaptation of Scrum that is always evolving to better meet our needs as they change.
We have two calls a week with the entire engineering team, including Calvin as CTO and Deanna as Chief of Staff and representative of the customer-facing organization, ie. support and concierge staff.
This is where we talk about upcoming work, clarify projects, review code, talk about impediments, and just check in with each other.
In addition, we use Slack for ongoing quick questions and calls. If there's something that needs to be resolved or answered outside of the scheduled calls, it's usually much more efficient to hop on a quick call to resolve it then and there, if possible.
We also use Basecamp for certain things like to-dos that aren't part of the immediate Project kanban board, eg. when interacting with support staff that don't have access to our Github repository, as well as for conversations that aren't ephemeral like Slack conversations tend to be (nobody wants to read through a chat log).
As part of the day-to-day, bugs and issues come up. They can either be urgent-drop-everything-and-fix, or urgent-fix-before-the-end-of-the-day, or not-urgent. If they're not-urgent, they go on a To-Do list in Basecamp, where we'll review and fix at least once a month. If they're urgent, they're posted in Slack, and we'll look at it as indicated.
How much support stuff comes up depends a lot of how much new functionality we've pushed recently. If there's not a lot of new stuff, things tend to be super stable.
We try to avoid deploying your stuff later than 3pm in your time zone, so there's still time for a quick fix later that day. If we suspect there might be more complex fallouts, we'll always deploy first thing in the morning. Usually the time from deploying a bug till we hear about it is very quick.
Simplero is mostly a pretty standard Ruby on Rails 5.2 app, talking to MySQL (MariaDB 10.2) and running on AWS. The website builder is written in ReactJS.
We do use a bunch of other AWS services, like ElasticSearch, Memcached, a PostgreSQL database, and others.
We have exactly one microservice, which handles video encoding, since these tend to run for a very long time, and the code rarely changes.
We have a ton of internal tools that we've built that allow us to be very productive. We love to build the tools that let us be more effective.
Our server configuration is managed using ansible, so everything's checked into github.
We're mostly full-stack people. Everyone does front-end, back-end, and devops. Everyone gets to work on their own features or tasks, and can of course rope in any other team member as needed for input and help and extra pair of eyes.
We like to find out where each team member is particularly strong or particularly passionate, and get them spending most of their time there.
Critical success factors
Judgment, the ability to quickly understand and navigate a large app, and the ability to understand the bigger context, notably our customers and the strategic vision for the product.
The only way I know to write great code efficiently is to have just enough thinking ahead, and lots of creative judgment while you work. What seemed like a great idea at first can turn out to be awful once you get to the code. That's when you must know to turn around and reevaluate. Is there a better way to do this? Maybe it doesn't need doing at all? What are we really trying to achieve here? What's a simple, elegant solution that solves a bigger problem in a cleaner way?
This is the most valuable skill for us.
I want you to be someone that I can trust to make great decisions. Which means sometimes you'll make awful decisions. That's fine, as long as there was a good reason for it, and we catch it and fix it quickly. Over time, you'll get really good at knowing which is which.
Coding is art.
Art takes creativity, judgment, courage, personality, integrity.
Be fierce with your code.