Growing Software Teams
Ok everyone… Confession time. Until a few years ago, I never imagined myself as a leader. I never thought I’d be leading teams of software developers, delivering simple solutions to complex problems. In fact, I was told in high school that I’d never be good at programming so I shouldn’t even waste my time… But here I am, leading software teams and teaching developers how to be extra awesome. If you’re a lead developer or manager, maybe some of my experiences can help you grow your team. Kindness, humility, positivity, and test driven development are the staples in my utility belt.
Part of how I help developers level-up is by constantly reminding myself to be kind and that everyone is going through their own struggles whether we realize it or not. Got a dev on your team that just won’t write unit tests? Try understanding why. It usually takes some level of trust/rapport for someone to be honest in these situations, so it’s best to be consistent in your kindness and empathy so that when these situations pop up, you’re in a good place to solve them. I love hearing “I don’t know how” from a developer in scenarios like this, because that’s a problem we can work together to solve.
In addition to being kind to individuals, another important part of growing your team is humility. I’m not just talking about “don’t be a jerk in code reviews”… What I mean is that you need to remember that the teams successes are not yours; they’re the whole teams. And, frankly, you probably wouldn’t have been able to pull it off without them. Always remind yourself and your team of this! If your manager recognizes your hard work, tell him you couldn’t do it without the others. When your team feels valued, they’ll go the extra mile. I’ve been on both sides of this “agreement”, and it really does work.
Another “soft skill” that can massively improve your teams productivity (and happiness!) is “positivity trumps negativity.” Last year, I joined a team of developers that could only be described as toxic. As individuals, outside of their work environment, each person was at least neutral if not positive. As soon as the team got together in our work area or a conference room everyones mood would drop. The negativity was palpable, and affecting our productivity. Conversations turned to arguments; PRs were ignored out of animosity; Release dates were slipping. I was doing everything I could to improve the teams morale and perspective, but my successes were small. Eventually, due to the teams low productivity, a new developer was added. I immediately took a liking to the new guy because he just radiated positivity. That same week, the Team Curmudgeon gave her 2 weeks notice. Within a week of her being gone, our teams attitude had done a complete 180. Management was now actually stopping by when executives came to tour our department! Features were shipping at a break-neck pace! We even started hanging out after work and going to lunch together, since the collective desire to push eachother into a pit of snakes had dissipated. Seeing how fast this change occured was almost surreal and, going back to my previous point: I couldn’t have done it without “the new guy.”
One last non-technical strategy/skill I’ve found to be very helpful is the ability to find the silver lining, or good side, in a situation. When I was a teenager, I came up with the idea of “I win. As always.” which has been huge in my success. This doesn’t mean that I go around acting like a jerk, making sure I always come out on top… It’s just a phrase I use to remined myself that no matter what, every situation has a positive aspect. When I tell myself “I win. As always.” It makes me think about how to turn the situation into something positive. At the very least, you can ALWAYS learn something which is a win in my book.
Now that we’ve talked about the soft, squishy, stuff… Let’s talk about the easy part of leading software teams: The technical stuff. Programming Is Easy, after all :) If you want the short and sweet, here it is: “extreme programming.” For a more pragmatic approach, let’s break XP down a little and see what pieces can be really useful. I’m a huge proponent of pair programming, as it has benefits on both the technology and human sides of our profession. Humans are very social creatures, and working alone in a cubicle for 40 hours a week is not optimal for our mental health. In IEEE Software, Vol. 7 Issue 4 a study was published that showed 96% of developers doing pair programming were happier than when they worked alone and 95% said they were more confident in their solutions. Imagine if every developer on your team were happier and more confident! With happier, more confident, developers reviewing eachothers code as it’s written you end up with fewer defects and cleaner, more reusable code. This means the organization spends a LOT less money building software. Want a raise? Help your manager deliver a project under-budget! You don’t have to pair 100% of the time, either. A lot of the teams I’ve worked with pair some of the time, and work solo some of the time.
Once you’re pairing on solutions, you should get even more eyes on the code by doing code reviews. The biggest secret to code review success is EMPATHY! You’ve written the worst code another developer has ever seen, I’m sure of it. I know I’ve written the worst code someone else has seen. We’re all on a path of constant growth and even 10x developers have “off days.” Code review is not a time to show off or stroke your ego: It’s an opportunity for you to kindly share your knowledge with the end goal being better software for your users. If you want an ego boost, start a blog :)
Another thing that a lot of teams struggle with is being able to focus. Developers need large chunks of time to solve difficult problems. I strive to give my team at least 3 hours a day of uninterrupted time. Get all your meetings done early in the day, and let the devs shred some code.
The secret weapon when it comes to making your team great is definitely test driven development. Doing TDD forces you to ferret out rock-solid requirements from stakeholders, because you have to have enough information to write your tests before you even attempt an implementation. Poor requirements are actually one of the leading causes of software developer unhappiness, and TDD can fix this issue (when done right). TDD also results in better-designed systems. This means fewer bugs, easier maintenance, and more profit. I can’t imagine a scenario where less bugs, happier developers, and happier business folks wouldn’t be a good thing.
To sum it up: If you want your team to be the best, you don’t need to spend your departments budget hiring “rockstars.” You’ve most likely got a bunch of “latent ninjas” within arms reach! Instead of replacing folks, learn how to grow your current team using kindness, empathy, and some process refinement. In the end, you’ll have a much stronger team that’s willing to go to battle with you no matter how daunting the task.
IEEE Study: http://ieeexplore.ieee.org/document/854064/