We all know that it’s hard to find good people, but hiring talent is only one aspect of what it takes to form a successful team. The world of software development is populated by many passionate and knowledgeable individuals; however, such ability is not always accompanied by the strongest of interpersonal skills. Rockstar developers may have the ability to be productive when working individually on programming tasks, but on larger, collaborative projects, technical skill isn’t everything. At the same time, not every developer you hire will be a rockstar, and it’s sometimes necessary to build technical competency from within.
Starting out as a solo developer at a burgeoning SaaS startup, I quickly found myself in the role of a team leader responsible for 5-10 members, depending on whether my product was an active priority at the time. I initially felt annoyed by the added responsibility, time spent managing was time lost writing code, and there was much to do. Over time I learned the importance of my responsibilities as a leader, not to brush them aside, and I developed an effective process that proved useful for someone who wasn’t a natural “people person”. Team members will be most productive when their objectives are clear and they’re working together harmoniously; the work required to facilitate this should not be neglected.
Although many roll their eyes at the prospect of “leadership advice”, I’ll share some practical tips on how to successfully onboard staff, build a cohesive team, and ensure that internal challenges don’t send a project off the rails.
Building a team
The first step towards success is hiring staff that fits your organization’s needs and dynamics. Luckily, here at Scalable Path, we have a wealth of talented freelancers to fill such roles.
Regardless of whether someone is working on-site or remotely, their abilities and overall “fit” must be considered. In a remote setting, this necessitates a certain level of autonomy, but the ability to communicate and engage with your existing team still matters. In fact, being able to share meaningful status updates, ask for help when needed, and provide support to others is crucial to preventing remote workers from becoming siloed. Just because team members don’t share an office doesn’t mean that technical skills should be the only consideration when hiring talent.
The next step after acquiring talent is ensuring your onboarding process successfully integrates individuals into your project. This means investing the required time and attention that a new team member deserves, from orientation onwards. Being thoughtful about this process lets you maximize team members’ potential and ensure that your project runs smoothly.
It takes work to successfully bring on a new team member and get them up to speed, there is a short-term negative return of productivity involved. Good leaders understand this and welcome the investment. For projects that are behind schedule and need help, the best time to hire was sometime in the past, and the second-best time is now. Part of the job as a leader is communicating these facts to stakeholders when necessary, and clearing a path for future success.
Here are four key areas to cover during onboarding:
- Documentation: Document as much onboarding material as possible. This should include an overview of your project, the technologies being used, and your team’s long-term goals. Provide access instructions for relevant resources and include the steps required to get one’s development environment up and running. Having things written down helps deal with the information overload that occurs when starting a new job, and reusing it saves time if you’re bringing on a lot of staff. Just be sure that you still engage with new hires – don’t just pile documentation on them and then move on.
- Assigning a peer mentor: Give your new hire a contact that they can go to with their questions while getting up to speed. This person should be a peer, not a superior, who makes it clear that they’re accessible and happy to help.
- Schedule check-ins: Make a point of scheduling time to check in with your new team member. Ask how they’re liking their new position, if they’re experiencing any struggles, and if there’s anything you can do to help. This will let them know they’re appreciated and help to uncover any issues that need to be addressed early on.
- Onboarding task: This is optional, but something I strongly recommend. If you don’t have an appropriate task that actually needs to be done, you can assign throwaway “full stack” task that represents the kind of work your hire will be doing. Touch all the relevant aspects of your product that you can. A task like adding a generic set of working list/detail pages should fit this brief. Go through your usual business process from assigning a task through to (but stopping before) merging code and deployment. This serves as a dry run for a hire’s first “real” task, exposes them to your tech stack and associated codebase, and provides a great opportunity for them to ask architectural questions.
This routine has helped me greatly during periods of growth or high turnover while still enabling me to focus on other responsibilities. For even more information on how to successfully onboard remote hires in particular, take a look at our post dedicated to the subject.
Supporting your team
My experience as a team leader wasn’t gained while living in a tech hub, but rather in a Canadian university town of approximately 500,000 people. This made team building challenging, and we often had to invest in developing talent in-house by hiring fresh graduates. It’s been said that “you go to war with the army you have”, which rang true in the sense that leadership and internal growth were necessary for us to find success. Here are some initiatives and practices which I found helpful to accomplish this:
- Introduce a 20% time (or some other percent) policy so your team can work on research and projects of their choosing in an area at least somewhat relevant to your space. This will enable them to keep their skills up-to-date and possibly lead to innovation for your day-to-day operations. Make a point to check in with team members periodically to see if they’ve come up with anything interesting – even consider booking a “show-and-tell” meeting where everyone is welcome (but not required) to share what they’ve been up to.
- Involve junior developers in code review. One of the best ways to learn a language or framework is by looking at code other people have written. Seeing unfamiliar syntax or approaches creates a jumping-off point to learning something new and potentially useful. This can be easily achieved by sharing pull requests in a common Slack channel and encouraging everyone to take a look, even if they aren’t “reviewers” of the pull.
- Run office challenges such as hackathons, traditional programming challenges, code golf, or security-focused CTF using languages and skillsets you want your team to develop. When I was noticing some SQL injection vulnerabilities showing up in our pull requests, I created a dummy website that was vulnerable to such attacks. I gave my team relevant readings and then ran a challenge to see who could hack into the site. It was a fun exercise that ended up communicating the importance of writing secure code and the steps required to do so.
- Provide a learning/conference budget. Also, consider going to a conference or meetup as a team. The benefits here are obvious, and it gives your team the feeling that they’re being supported.
- Assign tasks outside someone’s comfort zone. The opportunity for growth here is clear, with the added benefit of eventually creating a team whose members are able to work on multiple aspects of a project. This helps mitigate the risks involved with one member of staff being the default go-to person for a specific function of an application. If the “log guy” leaves, you’re okay because other people have experience with logging. It also makes task assignment easier during crunch time.
- Provide the vision. For work to be meaningful, there has to be a reason behind it. If you’re producing something that’s innovative or will help people, that will go a long way to motivating your team. For more mundane work, the goal of producing something that is well-crafted can serve as a satisfying pursuit. Routinely meet with your team and provide updates on the bigger picture: goals ranging from long to short term, overarching objectives, and feedback on progress so far. Approaching and passing milestones in a project is an opportune time to do this.
Teams benefit not from being siloed, but instead from being collaborative with a focus on mutual improvement. In a constantly evolving industry, it’s important to keep up-to-date with growing trends and technologies. Building talent in-house will allow you to do this while addressing any shortcomings in your current team composition. Stay engaged with team members and put aside time to foster growth and development – these things are necessary for long-term success.
This is often one of the most challenging aspects of running a team, and there’s no exact science to it. In a broad sense, lending a sympathetic ear and working to diffuse situations is the way to go. I found that the role of team leader is often also the role of team therapist. Listen to your team’s concerns, communicate your plan to help, and then check back in later with your progress.
A common source of conflict among software teams can be code reviews. Developers may be inclined to take criticism of their code as personal criticism, but this should not be the case. Feedback should be constructive and framed in a way that focuses on the potential for improving the code, taking focus away from the developer who wrote it. Comments can be couched along the lines of “I think this block can be improved by doing…” or “something may need to be added to handle the case of…”, instead of “this is written poorly” or “you forgot to do X”.
Even if you aren’t involved in code reviews yourself, you may need to step in if they appear to be creating conflict in your team. It may be necessary to remind the reviewer of how they should approach providing feedback, or the developer with regards to not taking critiques personally. Creating an environment that fosters and welcomes constructive criticism will result in an all-around improvement of your project’s outcomes.
A second source of conflict, and in the same vein as code reviews, is that of technological disagreements. Developers are sometimes known for being opinionated about what technology or approach is The Right Way Forward. Debates are often healthy and an effective mechanism to solving problems or charting a course, but it can sometimes become necessary to intervene and move things along, especially if the discussion is no longer constructive. For smaller aspects of a project sometimes making a decision and then moving forward is what matters, and “good enough” is good enough for the time being, instead of getting hung up on minutiae.
Beyond that, you’re likely to face the usual gamut of problems that can occur in the workplace, which needs to be addressed as you see fit. If your project is struggling, don’t catalyze negativity, and take aside and speak to anyone who is. As long as the prevailing attitude is one where there is a clear road to success, your team members will be happy to follow along with you.
Getting to “Gel”
The authors of Peopleware (well worth a read for anyone in the software industry) introduced the concept of teams that “gel”, meaning their ability to work well together not because of the talent of the individuals, but in a holistic sense where the whole is greater than the sum of its parts.
It’s not simply that a team that’s gelling is one that’s productive and free of conflict, but it’s also that team members are supporting each other and working harmoniously together. The team becomes a network for support and innovation, where members’ primary concern isn’t their own success, but that of the team and project of focus.
It’s an elusive goal that depends on the personalities, environment, successes, failures, and leadership amongst a team. There’s no exact science to achieving it, but initiatives that fall under the nebulous heading of “team building activities” can be a good place to start, as long as you aren’t bringing in dry guest speakers and doing trust falls.
Refer back to the “Supporting your team” section. Group activities such as office challenges, attending conferences together or sharing the results of 20% time fall under this category. Going out for drinks or ordering in pizza to celebrate a major release provides a great opportunity for a team to bond.
For remote teams, this can be more challenging. It’s also important to not neglect given the isolating nature of remote work. You can leverage your team’s Slack #random channel to spark discussion – ask if anyone has been working on an interesting side-project lately, or if anyone has some good Netflix recommendations. Consider starting a book (or other media) club where those interested can progress through and discuss a shared interest. Take the time to ask how someone’s weekend went at the start of a call. Even little things like this help foster a deeper connection among team members.
Teams that gel are likely to give each other more leeway or be willing to go the extra mile when needed. Just remember that this works both ways, and “gelling” isn’t a cynical tool for achieving productivity – it’s something that improves the working environment for all parties. Its key aspects are empathy and understanding of the strengths and weaknesses for everyone involved, and a genuine willingness to help for the sake of helping.
It takes work to lead a team. Leadership in software teams begins at onboarding, is practiced during day-to-day operations, and faces its greatest test when making hard decisions. It’s not simply enough to rely on talent and skill to deliver a product, someone must be righting the ship as it sails. If you’ve read this far, you may be that person. However, even those not officially in a leadership role can lend a hand and speak up when they see potential areas for improvement.
If your team is working well together, that’s great – keep doing what you’re doing, but see if there’s a way to refine your process. A nudge in one way or another may lead to things running even smoother. Otherwise, if your team is struggling, it’s time to get involved. Lend a compassionate ear to your team members, identify the pain points, and do what you can to address them. Make sure to stay active, deliver on promises to help, and check back in to see how things are going.
Be sure to remember that you’re dealing with individuals who have different predilections and needs. Be supportive, and take the time to foster a sense of community amongst your staff, and provide a clear direction for the future. Not every moment has to be dedicated to productivity; time spent on team building is not time wasted. Once you have a team that’s working well together, everything else seems to fall into place.
Are you looking for help with your next software project?
You’ve come to the right place, every Scalable Path developer has been carefully hand picked by our technical recruitment team. Contact us and we’ll have your team up and running in no time.