Empowering a Small Tech Team to Take on More Responsibility

Problem

Climb Credit has a fairly complex product with a broad surface of area and many different types of stakeholders who are inherently connected. As a financial services company powered by technology, one of the challenges for me as CTO is working with a smaller team to still be able to create a robust technology platform that satisfies our operational needs while providing a great student experience.
The problem I found myself with is how I could enable a team to punch above their own weight and take on the responsibilities typically taken by a larger tech team.

Actions taken

• Most startups and engineering teams, especially in non tech companies, are going to be working with constraints and need to get a lot out of a small team. Drill down and determine what makes your team effective, what drives value for the company and try to bring that out not only in your engineering processes, but also in your key principles and values so you recognize what defines effectiveness and good stewardship of your product. Then empower your team to run with it.
• Build a team culture where your team is empowered by the context to act like product owners. One of the roles I play is to streamline the process for the team, but also enable the team to roll with the punches and move that process along on their own.
• One of the biggest pulls for me was creating open communication channels within the company to have feedback not only from the bottom up and top down, but laterally as well. We have teams in our company that represent each of our stakeholders. We leveraged tools like Asana to consolidate that communication and feedback. Then we set it up such that our engineers were empowered to own specific parts of the product and act like product owners.
• We were lucky that the engineering team already had great people who understood our business and the product, so my goal was to ensure they stayed connected with the rest of the company and help them be independent in moving the platform along.

Lessons learned

• Trust and empower your team.
• Although having engineers act as product owners is not a traditional approach, it was very successful for us. It led to a number of improvements and changes in the platform that allowed us to help more students. It basically doubled the number of students we could help in a single day.
• In a traditional tech company, you would have a much larger technology team with product managers who provide context and can give engineers exact specifications on what is being built. In any start-up, but especially one with a lot of moving parts, engineers always need to be able to adjust to shifting definitions of requirements.
• There is a perfect prototype of an engineer that works really well for us. One who is product minded and enjoys working with stakeholders to solve problems because the answers aren't always clear. Make sure your engineering team, especially in a cross functional company is never siloed and is always plugged into stakeholder feedback. The further removed the more difficult it becomes for your teams time to be focused on the most important and high value projects. Especially when they are not strategic projects, but the things you are doing day to day because it becomes hard to prioritize.
• There was a variation in the agile process that helped empower engineers to act like product owners, but also created open communication mechanisms with the rest of the company in the absence of a traditional product management organization.
• Creating channels of communication was easy because you show the issue management system and templates to follow, but getting that adoption through the company took a few months. A key takeaway from that is it's not about evangelizing it to your team, but to the whole company and showing why it's beneficial in order to gain their trust. In a startup, you are always short on time so nobody wants to dedicate time on process until it becomes important. However, in a tech team, especially if you want to implement things a bit ahead, make sure you recognize when process needs to be implemented and understand how far in advance you need to do that so as to manage adoption. Then, set up a continuous checkpoint of what is working or not in that process. Do not be afraid to break that process entirely as the team shifts and needs more specialization and ways of distributing work.
• This approach is interesting because it has some drawbacks as well. When you empower engineers to act like product owners and to be product owners, you are essentially diverting time away from their core functionality to talk to stakeholders. This can be distracting. It's about finding the right level of process for where you are as a company while still maintaining that connectedness. For example, we are going from 10-20 over the next few months and are now starting to bring and form a product team to streamline our processes even more, but while still preserving what keeps our engineering team successful.

"Trust and empower your team."

"Although having engineers act as product owners is not a traditional approach, it was very successful for us. It led to a number of improvements and changes in the platform that allowed us to help more students. It basically doubled the number of students we could help in a single day."