Improving an Underperforming Team by Instilling in Them a Sense of Ownership

Problem

I inherited a small team of one senior and several junior engineers. The amount of work produced by the team was not comparable to any other team of the same size. The work itself was not tangible, the quality was not satisfactory and there were always delays.

One of the main problems was that the team was responsible for a great number of things. The senior engineer had been on the team for six years and carried huge baggage of working on multiple projects that spanned six or seven different projects and applications. With all the accumulated knowledge he would get pulled into six different threads and was not able to entirely focus on one project. People on the team would typically work off of the highest priority thing that would show up on their To-Do list. Since they were supporting six or seven applications at the same time, the constant context switching was diverting their focus. The breadth of knowledge that was demanded was hindering them to acquire the depth of knowledge and due to persistent context switching people were never confident enough to develop specific expertise.

Actions taken

I first identified the problem -- a senior engineer was overburdened with all the knowledge he accumulated over the years and I had to take that load off by gradually distributing that knowledge across the team. I split our small team into smaller squads within the team; e.g. two people would focus on footer service and two others on SEO. After a while, they knew down to the smallest details what each service in their focus was doing and were able to document that and create run-books. Instead of working on the next highest priority, they would work on the next highest priority within their area of focus. As they started leading specific services they understood the importance of documenting and started creating diagrams, Wiki pages, and run-books that would enable the next person who would step into their shoes to continue with the work seamlessly.

Split into small squads I noticed how keen they became to take ownership. They would still reach out and consult with the senior engineer but would claim responsibility and ownership over whatever they were trying to build. Also, we would have monthly brown bag sessions during which they would present what they have learned about the service during the previous month. That way, in case we needed to shuffle people around, everyone would know what was going on.

Within six months we moved from being perceived as an underperforming to a great team. Other people wanted to join this team because it was well organized and we could show tangible improvements in metrics that mattered to management. We slowly started to grow; from four people we soon reached nine and the biggest win -- just before I left -- was that the team was assigned the most ambitious project related to the next generation product.

Lessons learned

• Lack of ownership is often the essence of any problem and my responsibility as a manager was to instill that sense of ownership into every person on the team. My role was to give them the right amount of heat but be careful not to burn them out. If at any moment they were stuck, they knew I was there to support them the best I could and that I was in the trenches with them. I think striking the right balance between giving someone ownership and providing support is crucial.
• People derive their confidence from either knowledge or motivation. You could be the most knowledgeable person, but if you are not motivated enough, your performance will suffer. Also, your lack of knowledge, in spite of your excitement and enthusiasm, would impact your confidence. If someone lacks adequate knowledge I can always provide training, help with networking, mentoring, etc. Motivation is harder to instigate as different people are driven by different things -- some are excited by new projects, some are scared by them. You will have to ask a lot of questions, a lot of the right questions.