6 ways to dramatically increase your software development team’s productivity
Software engineering is a beautiful thing. It tackles unsolvable problems and opens doors to innovation never before possible. The ways to apply it to problems are boundless and flexible.
As a wise developer friend once told me there is a reason they call it “soft”ware and not hardware.
“Soft” meaning that in the same ways it can be limitless, adaptable and malleable. However, it can also be complex, ugly, disorganized or convoluted. But most likely, it is all of these things at the same time. That dichotomy is the reason why development teams can appear stuck in the mud when deadlines are looming or flying high and overdelivering when unexpected. So what are some ways that you can support your development team and make fly high more common than being stuck in the mud?
Our team at Novvum has had an amazing opportunity to work with software development and product teams of all sizes. Here are some of the common themes and trends we have recognized during that time:
1. Encourage exploration of cutting-edge technologies, frameworks or libraries
This is a simple concept that can be difficult for some teams to implement. It is normal to grow too comfortable with a specific technology or convention. Promoting an environment of learning and exploration will reduce the possibility your team becomes stagnant or disinterested.
Finding new ways to solve problems, will push developers to become better at adapting to new unexpected situations.
The process of continuous learning will not only introduce you to new ways to deliver better software but will most importantly, keep your team excited and motivated. New ideologies will open your developers to innovative ways of thinking and ultimately, a more exciting and productive developer experience.
Here are a few of the rising technologies we are excited about:
If you need help vetting open-source projects, this article by Novvum’s CTO Rohit is a great read: “Successfully working with open source software”
2. Supporting your current developers is just as important as hiring new ones
When looking at your development team, you should see them more than just a bunch of technical code writers. If that is not your mindset then you are likely not doing enough to support your team. A development team should include project managers, designers, QA team (or if you are lucky, test engineers) and interns.. lots of interns.
Interns are always nice but joking aside, it is paramount that you provide your team with support. The same way a basketball team needs role players to win, a dev team needs supporting personnel and access to developer tools in order to be productive. Hiring additional developers is not always the answer to increased productivity.
Instead, try studying your development process to find areas where it feels backlogged (See point 5 below). If you notice developers are stuck waiting for their newly built features to be tested, put together a better or more automated QA process. If you find it common to need multiple revisions to complete a feature, you may want to improve the way you spec and design your feature requirements.
The key is that supporting your team is just as important as growing your team.
3. Third party services should always be evaluated prior to building something custom
This may seem counter-intuitive to some. “Why should I pay for a service when I have a team of developers who can build it?”
Well, there are quite a few reasons looking at these services is worth the effort:
- Even if you don’t choose the service, your team will learn a lot! One thing I have always found useful as a developer is looking through other teams applications, code, and feature-sets. This isn’t much of an epiphany as this is common with almost anything creative. It is considerably easier to improve on things already built and to learn from others mistakes. When evaluating the best approach for a new set of features, reviewing an established product or services could provide invaluable inspiration and insight to your teams
- Third-party services have been solely doing that “thing” for a long time and have become the experts. Realistically, your team is not an expert in everything. Of course, your team of brilliant engineers can crush most tasks but wouldn’t it be great if you could rely on a team who has spent endless hours finding all the potholes and landmines for you? Instead of running into unforeseen issues halfway through the project (see stuck in the mud reference), focus on how you can integrate and roll out and established service to your end users.
- Bonus: Show me the money… and time! A consistent theme I see with clients is the worry of adding another paid third-party service to their stack. It’s just another company you are going to have to dish out monthly subscription too… Well, it may not always be the case, but consider the opportunity cost with having your internal development team building the desired functionality from scratch. If you place a couple developers on the task of fully building the features, that may mean you are removing those man hours from other company or tech initiatives. That could result in tens of thousands of dollars and extended developer time going into the cost of a feature that has already been perfected by another group of developers! Not to mention, the upkeep and maintenance you are now solely responsible for.
6. Limit the time spent on a particular tool, convention, service or process (sunk cost fallacy)
“The sunk cost effect is the general tendency for people to continue an endeavor, or continue consuming or pursuing an option, if they’ve invested time or money or some resource in it,” — Time
This applies to both of the prior statements and should always be promoted. Make sure that your team doesn’t spend too much time obsessing over a specific tool, convention, service or process if it is continually causing issues or is not working as intended. It is natural for people to believe that because so much time has been spent working with a specific tool or doing something a certain way that you have to stick to it until it works as originally imagined. Just because it was the choice made with good intention, does not mean it is the best option. Humans are wrong all the time and developers, as weird as we can be, still are humans.
Instead, push your team to adapt. Installing a process that limits the time used to build a certain way or with a certain tool can promote creativity and eliminate blockers. If something is not working, don’t fall victim to the sunk cost fallacy. Don’t be afraid to move on.
5. There needs to be a process for the process
It’s not enough to just implement a development process. It is important that you actively critique and improve it over time. Iterate on your process the same way you iterate on your product. Here are a couple simple ways you can start analyzing your team’s process:
- Start collecting process KPIs. Don’t collect too many but do collect ones that give insight into the effectiveness of your process and how modifications to the process affect the results.
- Review parts of your workflow that are slow and start implementing new experiments. If you are gathering data on your team's development velocity you will be able to quickly determine if experiments have a positive or negative effect on production.
6. Work flexibility is important. Sometimes working late at night is just better...
This may fight a bunch of traditional norms, but I really believe that being flexible with developers hours will lead to a more productive and happier development team. For the doubters looking for the data, I’ll leave that to the study referred to in this Forbes article… In my perspective, engineering requires deep focus and concentration. It is hard to force yourself to think critically for 8 hours straight without breaks and through distractions.
Many of the developers I have worked with agree that sometimes more gets done after 10 pm. There are fewer distractions and less pressure. Maintaining a state of deep focus becomes easier when you have no other expectations. It’s important to provide your team with the flexibility to work on projects when they are most comfortable. Sometimes that may be late into the evening…
Share your thoughts!
Of course, not all of these will work for every team but when you recognize themes in productive companies, it is important to take notice. I would love to here interesting ways your team has increased productivity.
Please feel free reach out and provide feedback!
Email — trevor@novvum.io
twitter — @thetrevorHeath
