How to keep your engineering culture while scaling your business
Our story: from 3 to 40+ developers.
A successful tech startup begins with a strong company culture. If there’s any group of people you especially want to keep motivated, it’s the people building your products.
A strong engineering culture isn’t the images of ping pong tables, free lunches and casual Fridays in the startup world. Building products isn’t as much about the perks as it is about the processes. Engineering culture to us means motivated team members who consistently create and maintain quality code.
A strong engineering culture needs to have certain systems in place that make developers accountable for the code they hand off, while tapping into the unique skills and personalities of your team members. What are some frameworks to start with? Here are some of our approaches below.
Size matters, just not in the way you think.
As a company with 40+ developers and designers handling multiple client projects, we have autonomous teams with a project manager (PM), tech lead, dev team with 1–3 people and an assigned designer to follow the project. With your baseline standard developer, you should be able to calculate the number of days needed for the product the client wants to build — if they want it faster, then you can put more people on it. The smaller size allows our developers to take ownership of what they’re building rather than handing stuff back and forth (even with Github). Pull requests are merged by the tech lead, so someone else will always check the code. After a merge is completed, our project managers will test and approve the feature.
When we say size, we mean the minimum viable team members to make a great product.
A small team structure helps improve:
- Focus: Small teams have one fixed goal and deadline, and the senior team members can spend more time to support each individual
- Cohesion: With 3–5 person teams, everyone can stay informed about all the working parts
- Interaction: Small teams can coordinate better for in-person meetings and share ad hoc information
- Visibility: Small teams make it much easier to catch road blocks, conflicts, and underlying problems
- Administration: Small teams allow one person to be the contact point and reduces the amount of documentation, paperwork, and bureaucracy
- Clarity: The team is able to keep track of all successes, expectations, failures and status changes (i.e. through a daily standup)
A good idea is a good idea, regardless of who thought of it.
As explained by Scott Cook, co-founder of Intuit, “Traditional management prioritizes projects and assigns people to them. But increasingly, managers are not the source of the idea.”
Seniority should not matter when debating ideas and solutions. Many tasks in development are quite straight forward, but how do you decide to use one framework over another? Should we be using a newer library that fits the project requirements better or a better documented one? Though solutions to such questions are often suggested by the tech lead because of experience, there should be active encouragement for the entire team to contribute.
Our project manager will go through each developer’s items for the day and the developer outlines what they will do. The rest of the team can contribute additional ideas or resources, such as a useful library. This task-based reporting gives everyone the opportunity to contribute daily, whether they’re a new junior developer or the tech lead. The conclusions and are documented on Waffle.io, which tracks issues on Github.
Leave no room for excuses to not share.
Open debates are vital for pooling ideas, regardless of whether they can get heated.
At Oursky, miscommunication is typically a source of disruption more than argumentative behaviour. This has taken the form of people not speaking up due to perceived seniority, people not asking for clarification, and/or developers not challenging PMs on requests that they know don’t make sense.
Transparency helps the process of contribution in cases like those above. Face-to-face communication within the daily standup meeting reduces the chances for individual conflict. Clear documentation of debates, problems, and solutions on Github helps team members focus on the issue, not the person. When the whole team can both contribute to and access information, everyone has a better chance to be heard, and thus to buy into the conclusion. The documentation is especially important for distributed teams so remote colleagues can contribute knowing the full picture.
By tending to the unique needs of your individual team members and providing them with multiple channels to voice their contributions in publicly accessible channels, you significantly lower the chances of individual conflicts. Rather than people needing to one-up each other, you create a culture of people keen to learn from their peers.
Say goodbye to code ownership.
Although code ownership certainly has its perks (control and credit where it’s due), a successful small team culture isn’t the place for it. Letting go of code ownership gets developers to think about readability and long term maintainability. Here’s a typical development process at Oursky to ensure code quality:
1) The PM assigns a task and the developers sums up what they’ll do at the standup meeting.
2) Developer completes the task within 2 days (longer tasks are further broken down).
3) Developer consults team members where needed (especially tech lead).
4) Developer sends a pull request when the issue is finished.
5) The tech lead checks and merges the pull request.
6) PM checks the feature is actually functional, then updates the client.
Thinking as a team encourages developers to consult one another as they go, even for small details if they think it will have a long-term implication. One of our developers asked about whether “setting” or “settings” should be the correct term and decided to refactor his code because he wanted to make sure others would understand in the future. It’s pretty common for a developer to completely forget the logic and context of her/his code from 6 months ago, so thinking as a team enforces best practices such as naming.
For an easy-to-follow reference dedicated to this very topic, you can check out this slideshow created by Edwin Kwok — one of our former developers.
Optimize for iteration speed.
Fast iteration comes in two forms. The first is bureaucratic, or having fast and effective process execution throughout the company, and the second is the actual product development. A slow bureaucratic process, such as having every level of management approve a new line of code or feature is a bottleneck that can severely slow down launch. It also leaves decision making in the hands of people who are far removed from the product (i.e. senior managers), which means more meetings need to be held to bring them up to speed if there is a disagreement.
In addition, a product with long cycles and huge overhauls means that engineers can’t see the results of their progress (i.e. that users are using their product). Both are time-investment risks and psychological drains if projects fall behind.
We recommend using Waffle integrated with Github to help teams see on a daily basis what issues need to be addressed. The PM is responsible for helping the team prioritize and delegating (including outsourcing) tasks so that the development team can stay focused. The PM takes new feature requests and works through the process below:
Process
- 1–2 Week sprint: defined by a collection of features and/or bugs introduced by the client
- If it is a requested feature, make sure there are enough details to work with. If not, bring in the design team to provide additional UX & UI support first.
- If it is superficial, such as copy content, delegate to writers.
- If an issue is a bug, make sure it is reproducible before assigning it to a developer to fix.
- If an issue becomes too big, break it down to less than 2 days.
Although we are a digital product agency, the barebones of this process can be lifted and placed into just about any engineering environment. Happy building!
If you found this piece helpful, follow our publication for more startup/entrepreneurship/project management/app dev hacks! 💚
At Oursky we’re all about helping brands and entrepreneurs make their ideas happen, as well as fellow developers — our latest project Skygear, an open source serverless platform for mobile, web & IoT apps — helps you build better apps faster. 😻
