I have spent several years as a Team Leader (also known as an Engineering Manager), heading up teams of about 4-6 developers from different backgrounds, seniority levels, and abilities.
The first time I led a team was during my army service as an officer in the elite 8200 unit. I oversaw a team of brilliant aspiring software engineers and our work revolved around making sure the right information made its way to the right places, at the right time.
While being a developer in the army is the dream of many young adults, this dream is usually accompanied by many responsibilities, in addition to those typical army-related duties. Managing people is challenging enough, without having to deal with other “side” distractions; soldiers who are currently on duty the exact moment you discover a bug in production, soldiers who are sick and, therefore, get sent home (also known as “gimelim”), or even soldiers who fulfilled their army duty and moved to work at a high-tech company or started their degrees. While little “blips in the radar” are common among any regular R&D team, it’s important to realize that you can usually ask the relevant person to fix the issue, have them log in from home, or from anywhere else they may be.
Dual Ownership To The Rescue!
Having to ‘manage my soldiers’ chores, vacations, sick days, etc. in addition to routine engineering activities, forced me to adopt the first guideline on my best practices list: dual ownership!
Let me explain; every server/microservice/component we created or were responsible for had at least two owners. This was not in name only (for official purposes), but rather, there were always at least two team members that split the responsibility, discussed, and made sure their “baby” was in good hands. When one of them fixed something, the other was informed about it and made sure to code review the changes and help as much as possible. During sprints, we used to switch between the developers who shared responsibilities and review the code as soon as it was completed.
While this might slow things down, and make tasks last a bit longer, its positive effects were also immediately made evident:
- The team developed a strong sense of responsibility and wanted to share the load as much as possible, be that load relevant to tasks, work, or even personal matters.
- Maintenance times were reduced significantly, and a strong sense of self-efficacy was felt when they were tackling a problem.
It Is All About Quality
R&D teams tend to shoot out code, sometimes without much regard for tests and coverage. In part, this is because it is obviously the least fun part of the “job.” As such, it’s hard to really blame developers for “forgetting” or neglecting this part. To change this, quality-related sub-tasks were added to each task (or assignment). No task is completed without these “built-in” parts: unit tests, integration tests (when needed), code review, and code coverage percentage maintenance. Soon enough, these practices became part of the team’s culture and a critical part of our discussions. It even caused our team members to engage in a little healthy competition.
I stumbled upon another solution that can greatly affect an entire R&D organization during my time at one of my previous places of employment: a “Quality Hackathon -” A group of people focusing all their efforts in creating tools and simplifying work around the quality of the product and code. The main point of these Hackathons is implementing the product/lesson into your routine. The ideas, products, and lessons learned must be incorporated wisely into the organization’s systems and tools or be “sticky” enough so that employees use them after the Hackathon is over.
Career Development
In every sprint, there are tasks that everyone wants to work on and tasks they’d never pick. There are tasks you can learn from, even though they may be repetitive and boring.
I try to balance these tasks as much as possible so that everyone on the team gets a chance to work on the “golden tasks.” I am usually able to make this happen, thanks to the dual ownership principle I mentioned before.
It’s also important to note that I do not see myself as above anyone. I often assume “annoying,” repetitive tasks myself, so as to show that I too can “take one for the team.” It isn’t too time-consuming, and it shows my team that everyone is responsible for the task’s success.
Share And Inform
The last thing I want to discuss is more related to the business side of operations than it is to R&D. Employees who receive updates regarding the company’s progress, customers, funding, etc., will be more involved and care about what they do. This transparency increases their sense of belonging and possibly makes them stay on the job longer. Make sure your employees know how valuable they are to the team and the company, not just in terms of salary and ESOP.
At the end of the day, I believe that beyond the big salary and the amazing perks we see out there today, people want to work in a place that sees them, treats them well, challenges them, and makes sure they constantly learn and advance within a pleasant environment. Shaping this environment through positive leadership can make a huge difference in hiring new employees and maintaining your R&D teams. Retain and nurture your employees as much as you can, instead of looking for new ones; it’s your ticket to ride.
