It’s one thing to use open source software as part of your tech stack, then disallow the open source attitude when it comes to owning code or even ideating among the engineers writing it.
Fast encourages the open source way for engineering teams
Today, "open source" designates a broader set of values—what we call "the open source way." Open source projects, products, or initiatives embrace and celebrate principles of open exchange, collaborative participation, rapid prototyping, transparency, meritocracy, and community-oriented development.
Fast engineers have deep domain experience; many of our projects are highly complex. Within each team, we structured it so the entire team is empowered to update their code, rather than territorializing it strictly to the original engineer.
This approach encourages our engineers to learn more, make wiser decisions, score the win of solving a problem, engage in active engineering, and truly embody a collaborative mindset, rather than creating knowledge silos and perpetuating a hands-off, no matter what environment.
“In a prior role, if I saw a change that needed to be made to code that another engineer on my team worked on but didn't fall under my domain, I would have to get their approval – and they would ultimately take over the task,” said Josh Hurst (software engineer, Frontend Team at Fast).
“Here at Fast, our work is team-owned. You have access to, and can help update, your team’s work with flexible parameters. And everyone here is empowered to learn as a result, rather than just notify the person who wrote it and walk away,” he added.
And, instead of being territorial over code or features, our engineers can focus on collaborating and unblocking, which allows for Josh to work on code that his teammate Joseph wrote a few weeks earlier, and move forward with a deployment. No waiting for Joseph specifically to sign off. No hoarding information. Backlogs and tech debt also get reduced.
See something, say something
Our engineers also take the “see something, say something” approach among themselves: they point out when they see things that can be improved. It doesn’t have to become clunky or outdated for a Fast engineer to notice, which allows them to be proactive in their own coding, ideating, or peer reviewing.
Creativity in our approach, along with making things go more quickly, makes up the core of what we do here. Instead of red tape, we put together a small Engineering Review Committee that quickly looks over proposed changes and gives approval, and our engineers are off on another coding adventure, instead of feeling like they got their hand smacked, did something wrong, or offended another engineer.
This empowers our engineers to make autonomous decisions – and builds community transparency into our default working mode
We still employ best practices (like pull requests), but abolishing the bureaucracy and red tape that so often comes part and parcel with engineering management also allows those managers to focus on mentoring and unblocking engineers, rather than protecting hierarchies. A community focus, even when you assign user stories, allows for more democracy and transparency among teams – individually and cross-functionally.
Following the open source way is incredibly important when teams are cross-dependent: rather than silos developing, or hoarding information or fixes, our engineers reach across whatever aisle needs a hand in that moment.
And this is just part of what helps Fast continue to be able to build our ships even while they sail.
Fast is hiring! Remote-first, awesome benefits. Join us!