Productivity is key to the success of any development team. Over the years i've learned a thing or two about keeping a team on track.
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:
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”
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.
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:
“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.
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:
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…
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
