If you're creating an engineering team, or you're part of an existing team, you've come to the right place.
Building teams is hard. It’s hard to balance finding the right people and hiring at the right pace to ensure growth. It’s hard creating a great onboarding experience so new hires feel welcome and are setup to achieve company objectives as soon as possible. It's hard maintaining a good culture as the team grows in size.
I’ve worked for a variety of software companies at different stages in their journey - from 5 employees to over 300 employees - from a consultancy, to startups, to a larger scale-up. I’ve witnessed and been part of various trials and tribulations of building a team that have resulted in different levels of success. It's been a rollercoaster of ups and downs and this has given me an insight into what I believe is required to create a successful engineering team - one that is capable of working efficiently, delivering value and being an enjoyable environment to work in.
Documentation
The push from the business to deliver features means other processes often take a back seat. However, it’s important to create some structure as startups can rapidly grow and onboarding new engineers takes time. Creating documentation in a shared space can facilitate onboarding, saving time and minimising confusion. You should spend some time creating documentation for code structure and system architecture, reference docs, how-to guides and information about processes. Of course be pragmatic here as it’s not realistic to document everything, especially in a small startup with limited resource, but some is better than none. Over time, maintain the documentation and keep updating it when necessary so it doesn’t get out of date or misaligned with the current state of things. Perhaps weave updating of documentation into part of your normal development cycle, or even better automate and generate it where you can.
Onboarding
Firstly, finding the right engineers for your team is super important and you want to find a good fit for the company, as well as the company being a good fit for the candidate. Having a strong interview process which focuses on both technical and soft skills, and taking time to be understanding of the wants and needs of both sides will help find the right fit for your team. Technical ability is a key component, but evaluating communication skills, willingness to learn and general attitude are key factors to consider - skills can be taught, attitude is more difficult to change.
I have seen onboarding of new engineers done really well and really badly. Setting people up for success from the beginning is the best way to ensure new starters feel valued and can get stuck into the role. Providing engineers with any equipment and account access they need to do their job is critical for a smooth onboarding, especially in the current working climate where we’re embracing remote-first and “in person optional” working.
In addition to this, providing new starters with useful information (like relevant documentation as mentioned above) can facilitate the onboarding process and enable them to get stuck in much quicker. Creating an onboarding checklist for someone to complete in their first few days, including things like environment setup instructions, encouraging interaction with other specific team members and getting familiar with documented processes, is a great way to set some expectations while allowing them to settle in. A great thing I experienced recently was encouraging existing team members to go out for lunch with new starters on their first day - it makes them feel welcome and is a chance to build rapport with people you may not have otherwise interacted with.
Communication
Transparency and communication is another critical concern. There are a variety of tools we can use to help us with this and each service a different purpose - email, Slack, video calls and in-person meetings. It’s common for modern software engineering teams to be small, agile, fast paced teams, which means people often wear multiple hats and need to be kept in the loop regularly. Here are a few suggestions on how to do this:
- Daily stand-ups ensure members of the individual agile teams can align with what they achieved the previous day, what they are planning on doing today and if there’s anything blocking them. The team can then understand what other team members are doing and help to unblock each other to achieve their sprint goals.
- Cross functional meetings with others outside the immediate team are great for planning upcoming work. Including “domain experts” in meetings, a concept from Domain Driven Design, helps to spread domain specific knowledge and context required for deeper understanding and improved problems solving.
- Regular company-wide discussion meetings are great to align individual teams with the higher level company goals and objectives. Daily team stand-ups and sprint planning can then refer back to these company objectives to ensure work being done is aligned.
In the remote-first world we live in it’s important that communication is considered carefully. Try to emulate in-person behaviour where possible - for example, don’t be afraid to just jump on a quick call, Google Meet or Slack huddle as it can be great to quickly hash out a problem and find a solution like you would if working closely with others in an office.
Feedback and collaboration culture
Closely related to communication, regular feedback through peer reviewing code and collaborative programming encourages engineers to share thoughts and discuss different approaches to problems. Give justifiable and objective feedback rather than it being personal or subjective - remember, it’s about the code not the individual and the purpose of feedback is to develop other engineers and improve the overall software quality.
My ethos here is more brains are generally better than one, no matter the experience of those involved. Every day is an opportunity for everyone to learn and if everyone in the team has an appetite for giving and receiving feedback it can really facilitate a team’s growth.
Closing thoughts
These are just some key areas to consider when building and growing a successful engineering team with a great culture. More to the point, not considering these things can lead to a breakdown in communication and collaboration which in turn inhibits productivity and the ability to deliver good quality software and can eventually lead to a bad engineering culture.
If you're not already implementing some of these things then I urge you to consider it. That's all for now!