How I Approached Fixing An Underperforming Team

Problem

I was hired to work as the Chief Technology Officer of a company that already had a technology team of 50 employees. However, it was by all accounts underperforming in terms of demands. The users wanted more throughput, higher quality outputs, the ability to change more rapidly, and more thought leadership in terms of driving the quality of technology and actual forward thinking about technology, as well as the appearance of forward thinking about technology. I needed to transform this organization so it could perform at this level.

Actions taken

The good news was that I had the authority, as well as backing from the CEO to make changes. I started off by gathering data from every technology team member in terms of their priorities, what they were working on, their process for understanding what they were working on, their understanding of the company's priorities, how they worked with others, and what tools they used. I then collectively reviewed the tools we were using, the platforms we were building with, the platform we were outputting to, and our collective process for engineering outputs. I looked at this from two levels - our product perspective and our corporate needs perspective. We then organized the team with logical departments so that we would have a function for project management, governance, and business analysis. In addition, we set up a department designated for development, a department for quality assurance and testing, a department for production infrastructure and operations, and a department for all of our corporate systems. For each of these departments we chose a designated leader and then the five leaders and I began operating as a technology leadership team. Next, we installed some more communication protocols so that everybody would receive more information about what was going on, at all levels. I kept up a regular cadence of the one-on-one meetings I had started when I was fact gathering, meeting with everyone in the department once a month for at least 30 minutes. This was the most important time of my day because I wanted everybody to be comfortable with speaking their mind. To me, the hardest thing to do is to change a culture. Trying to build an environment where people are encouraged to speak their mind and where the best ideas win is difficult when your team is used to an environment where ideas aren't welcome and where someone with a bad idea is punished. I wanted to create the opposite would be true - bad ideas are awesome because they tell us what not to do. By starting with making people comfortable with talking to me one-on-one, and letting them see that I really meant it when I said I wanted to hear all of their ideas, this was able to create an open, trusting environment. In turn, this created an idea meritocracy where people felt confident speaking their mind and giving their ideas.

Lessons learned

When I arrived, the team was attempting to do one release a week on a Wednesday night. They would frequently be there until the middle of the night and about half the time the release wouldn't work. I'm generally against all-nighters because you get very little returns for work that's done after a certain point of time and people will be useless the next day and perhaps even the day after that. By putting in new technologies, new processes, better testing, and better accountability, we moved from weekly attempts to releasing multiple times a day, resulting in a success rate of well over 90 percent. Thursdays went back to being productive and our productivity increased significantly. We got so good at it that we put in a rule that said if you were trying to do a release and it failed for more than half an hour, you would have to stop and kick it back. Our developers wouldn't have to wait a week to release it again, so they were less frustrated and releases became less rushed and urgent. In terms of enabling the idea of meritocracy, we actually became more of a thought leader, we were able to demonstrate that we were an advanced technology group. This meant our partners could look at us as a company that could provide them with something that was really advanced.