Move faster and break less: why start-ups should follow best practices

Classic start-up culture is all about disruption. Move fast and break things, right? Not according to Sudnya Diamos, founding engineer at Coactive AI. Following best practice is the surest way to save time, improve outcomes, and boost morale. In this blog she outlines how best practices allow the engineers at Coactive to thrive.

Why best practices are key to success

Divergences aren’t a problem when you’re a small team, but when you scale up to ten, or a hundred developers, you have to be aligned. If you don’t explicitly standardize team processes, people will naturally follow their own style. A freestyle approach like this introduces friction, which only gets worse as your team scales. Engineers get tied up fighting fires and fixing bugs, when instead they should be developing new features. It’s a trap many start-ups fall into, and one I’m determined we avoid at Coactive AI. Instead, we’ve been intentional about how we want to work.

Creating a shared code of practice across the team

To create our internal best practices guidelines we identified three priorities: internal communication, team velocity, and our learning culture. We then agreed on how best to maintain each area – starting by looking to emulate larger successful companies. This ensured our processes would be built with scaling in mind. Let’s take a closer look at how these core pillars have been implemented.

Our approach to critical feedback and communication

For feedback we like to use Netflix’s 4A model, whereby feedback is assistive, actionable, appreciated, and freely accepted or discarded. We also follow an agreed team etiquette, such as assuming positive intent, respecting each other’s time, and using set communication channels. The positive intent piece is key. In fast-moving feedback contexts it’s easy to lose nuance in written communications, so our culture is to default to positive assumptions about colleagues’ intentions.

How we optimize team velocity

We follow agile methodology and plan our activities as iterative fortnightly sprints. We run our sprints by clearly defining roles and objectives, and giving people clear responsibilities. We offer a light-touch in guideline documentation, so that instructions are concise and usable, rather than being unwieldy or overwhelming, especially when we’re onboarding new members.

Teams mindfully allocate their tasks, considering their other responsibilities in a two week sprint, and considering how new tools or experiments will fit into the broader product roadmap. This helps teams feel like they’re able to deliver the core features they’ve promised.

At the end of every sprint we have a retrospective. This faithful practice allows us to acknowledge wins, and identify avenues for improvement next time.

This cohesive, time-bound methodology is important for interdisciplinary, interdependent teams. Let’s say we have an application team, a dev comms team, and another team. It’s important that feature requests can be slotted into a slick system across these teams to assign a product manager, get rapid feedback, troubleshoot at stand-ups, iterate over two weeks, and do a post-sprint retrospective.

Our culture of learning

As a team, we support each other to keep progressing and growing; constantly taking away actionable items from our learning. For instance, we have a weekly book club where we read and review deeply technical books together. The discussion allows us to establish a shared vocabulary and create mental models about those topics.

We also do lunch-and-learns on Wednesdays, which give everyone a chance to present on a topic they’re passionate about (and pick the restaurant we order team lunch from!). For instance, Danielle has presented her research on Black English. It’s not directly relevant to our work, but it was super interesting, and everyone felt a benefit from the learning experience especially because it supports Coactive AI’s wider cultural principles.

Our co-founder, Cody Coleman, is also great at regularly securing external speakers to come and talk to us each month. They share their business and technical expertise, and we get to ask them questions in an informal context. External learning is super important.

Engineering examples of best practice

As discussed earlier, our engineering processes are designed to be scalable. For instance, we go from local to dev then staging and production, because having a local development environment is the fastest way for developers to test and iterate on their code in a tight feedback loop. (We use localstack for this.)

Pull Requests (PRs) are another example. A PR is created in line with our standard templates, and can only be submitted once it has passed all checks. At the point of submission, the author must select an appropriate member of the team to review it and provide feedback within twenty-four hours to support the teammate's velocity. The PR submitter explicitly assigns the PR for review to a specific owner and tags them on a dedicated Slack channel.

We automate changes like whitespaces via auto linting, documentation, import order etc. so only the actual code updates are shown on PR, which makes the review process more efficient and brings attention to the core logic. This combination of approaches minimizes errors, improves transparency, and improves team velocity.

How we handle patches and compliance

In modern software development, updates and patches are released weekly, rather than months apart. For expediency, we use continuous integration and continuous deployment. We’ve set up an AWS pipeline to support software patches.

Compliance is very important to us too. There are certain certifications you need for enterprise customers to work with you. We're already SOC2 compliant! We ensure key requirements are included and documented as part of our product design. We use software to put controls on things, too. This automates parts of our risk management by making it impossible for people to make certain mistakes. For example, to encourage R&D while minimizing risk, we have a sandbox area. This allows us to freely experiment without breaking something being used by current customers.

Other concepts we believe in

Time planning is critical – as a rule, our engineering teams don’t have meetings after lunch. This gives everyone 4-5 hour focus blocks to get work done after the morning is spent collaborating creatively across problems.

We also thoughtfully define interfaces and aspire to have a strong unit test model. This means that when features progress to the next level of development there will be fewer bugs to fix, and fewer knock-on-effects on other features.

A key value is being prepared to ask for help quickly. This ties in with our collective growth mindset and commitment to ongoing learning, which I’m very proud of. Oh, and heads up, a team favorite: if something has to be done more than three times, you have to automate it.

Summary

We have been mindful about our engineering processes from the beginning at Coactive AI, and have established shared principles of best practices across the team. This helps us to operate efficiently, supportively, and scalably.

Our key values are: constructive and transparent communication, respecting each other’s time through meeting-free windows and agile sprints, and continuously learning together. Best practices are core to our philosophy and our success. If you’re interested in joining our team, check out our job openings.

At Coactive AI, our culture is our number one product. We pride ourselves on having a truly collaborative, diverse, and ever-learning team. We’re also the industry leaders for analyzing unstructured image data, and we’re hiring.