Having a dynamic team is one of the most important traits for small businesses. A typical day will likely involve many team members having to wear many different hats of responsibility and ownership. For example, your UI/UX designer may have to write some code, your developers may have to participate in user discovery meetings and your HR department will likely… well honestly be non-existent and require some conflict resolution skills from all members.

We at Harled are no strangers to wearing multiple hats on the day-to-day, specifically when it comes to our engineering process and team. We all love to try new, sometimes daunting, tasks and we've seen some great personal development come from it:

• Members who typically wouldn't lead tend to self-propose for leadership roles that motivate them.
• Members see larger technical growth when given a larger effort to manage. Such as setting up a test suite or optimizing our development environment.
• Trust and collaboration increase while we share and develop skills for our new initiatives.

To provide scale for how much our engineering team structure changes, below is a list of the 5 times in 8 months we drastically changed for the betterment of our clients:

January - February

This was our kickoff to sprinting in 2022, the second time the project had ever used sprinting to track work and estimate outcomes. We had a team of 7 with the following positions:

• Team Lead: In charge of long term success, team health and performance.
• 2x Junior Full Stack Developers: Each led a team of 2 coop students in charge of delivering the sprint work as well as code-review for every pull request.
• 4x Coop Developers: Support team initiatives by taking tickets on an individual basis, onboard as fast as possible.

March

We found that we were spending an absurd amount of time in meetings which could be avoided with extreme programming (XP). This was the first time we had considered doing this outside of onboarding.

Outcomes:

• Each team of 3 would tackle one ticket at a time with a rotation on who is the lead on each ticket.
• No more time in code review meetings, all of this time is filtered into the XP session.
• With each ticket the responsible team was better-able to deal with improvements or regressions over only having one person fully understand the ticket in the previous iteration.

April

We swapped a team member of many years for a relatively new member and had to restructure yet again. We designated a quality assurance team in charge of the codebase health and our test suite.

Outcomes:

• Each team member had to learn and contribute to our test suite
• Members were able to callout which team they would prefer to be on and were ultimately more engaged in their work.
• Each team member developed a strong understanding of our development environment and contributed to its performance.

May - August

We said goodbye to all four coop students and onboarded a new member into a Junior Full Stack role and welcomed yet another student. We continued with a dedicated quality assurance effort and stood up another team to handle internal engineering tasks such as dependency management, code refactoring and bug fixing: Engineering Core. Alongside this we had a Projects team in charge of larger scale initiatives such as upgrading our front end, docker images, etc.

Outcomes:

• Our team became highly specialized in RSpec and testing Rails applications.
• Our team learned and implemented Cypress for End-2-End testing.
• The core team was able to dedicate more time back to the client with bugfixes.
• The projects team could specialize in technical domains without interruption.

May - August

In August we said goodbye to two Junior Full Stack developers leaving our structure as:

• 1 Team Lead
• 1 Senior Developer
• 1 Coop Student
• 2 Junior Developers

We came back to the conclusion that flattening our team structure will help ease some of the admin overhead we were experiencing with the previous team size. We are now back to a simple, single-celled, development team as we await the next big change.

Outcomes:

• To be determined!

Conclusion

The point here is we have learned to thrive on change rather than force unnecessary structure on our team(s). We also have learned to thrive on adversity given sudden onboard/offboarding of members and challenges that arose situationally throughout the months. Stay nimble, stay humble, and keep doing what's best for the entirety of your operation!

Interested in working for a team that is dedicated to an important mission and building the right team needed to achieve big things? If so, have a look at our current opportunities.