Learnings from managing people

Background: I’d never managed a very large team (more than 3 people) before joining BookMyShow early last year. The last year and a half have been quite an overwhelming learning curve for me as the indirect team I manage is touching a team of 12 product folks + a 65 member design team + a 70 member operations team. Using the Jacobian inversion principle here to jot down notes of the mistakes I made. Publishing this just in case first time managers find it useful.

My biggest learning: Focus on speed, the process not the tactic

As an individual product owner (PO), there were three golden tactics I used over and over for increasing team productivity and they worked incredibly well.
A/ Never enter a meeting room without a specific agenda.
B/ Never walk out of that room without a solid decision taken even if you disagree with it. Leave no ambiguity.
C/ Take decisions fast. Over slack, email, whatsapp, insert favorite app, be instantly accessible and decide instantly. Usually, the cost of reversing a bad decision is lower than sitting on it.

These tactics alter considerably when you’re leading a large team. To the extent that I had to unlearn them entirely and focus on processes. Today, if I enter a meeting room with an agenda mindset than a learning mindset, it’s a disaster. The problem is, as an individual product owner, even in very complex projects, I had data for the most minute points at the back of my hand. Now I just have the business context and a sketchy to decent idea if the data seems legit. Secondly, I don’t have as much time to prep for meetings as I used to. I have to rely on the speaker’s persuasion skills to form an opinion and lean on one side unambiguously to help _them_ achieve _their_ agenda. The third part is really tricky. When I took fast decisions as a PO, it was with a clear understanding that I still need to convince a peer / senior and I’ll handle that part later. Today, the problem is, when people in business or engineering or design ping me about a decision offline, it is sometimes with an explicit intent to undo something work-in-progress that a PO is pushing hard for.

The best way to increase speed as a company process then becomes counter-intuitively, *not* driving decisions but 
A/ acting as a smart conduit that knows when to step in and when not to
B/ managing inter-personal conflicts in large meetings to make sure that roadblocks in the way of agenda-driven POs are minimised
C/ following up to make sure things decided in meetings are running on-track to avoid surprises (and to my sad realisation, subversions)

2. Organization structures should enable healthy conflicts

I underestimated this part considerably since in my 10 year old career, I’d never really thought through a reorg from scratch. Around the time that I joined, one of the biggest issues I saw in teams with low output cadence v/s high performers was three fold:
A/ Poorly articulated mission statements which ended up giving teams responsibility for specific features not overall goals
B/ High dependence on other teams for success e.g., closely related features having multiple engineering / product owners
C/ Inter-personal conflicts within teams which made it hard for them to succeed as a group

My first attempt at this problem was to work with engineering and carve out a structure which gave teams clear mission statements and SMART goals. E.g., Discovery is now a team that owns home page, listing pages and search with a clear goal of getting more people to visit a movie / event detail page from the homepage. There could be a 1000+ ways to do this. All of them fall in that Product/Tech/Design owner’s ambit. While doing this restructuring, we discussed each candidate for weeks till me and the engineering head were convinced that this is the right thing to do.

While this really helped overall; we got the people mostly right and made great progress on goals despite announcing them later than we should’ve. We messed up three super-important things:
A/ This gave people fiefdoms. The person whose domain and goal it was felt like anyone making a change on that topic must get explicit approval from them. This crept in slowly over a couple of quarters but it seriously impacted the way people took initiative to fix problems for the firm overall.
B/ On the other end, it made it okay to be less than transparent about major architectural changes across teams and platform level initiatives with a feeling: “since nearly 95% of the work is mine, the person owning the 5% should fall in line and help”.
C/ Like in most cases, we’re a leaky bucket before we could announce formally, people knew about the new structure and changes. This resulted in weeks of uncertainty during transitions and lost productivity

My learnings from this, and I could again be getting this horribly wrong. I’ve read thousands of articles but there seems to be no guidance on doing this well:
A/ Publish my own goals and pass on one primary goal to the teams. Give people freedom to pick any goal as a secondary one and crack it if they can. One dummy example, one of my biggest priorities till the end of the year is to increase revenue which I can do via: increasing traffic, conversion, selling more expensive items, cross-selling, adding new services like advertising, etc. Parts of these funnels are someone’s primary responsibility but anyone (PO, engineer, designer or even intern) running an experiment is fair game. Teams must have a healthy amount of competition and there must be a reward for helping the firm overall, even if two or more parts of the firm end up working on the same thing for a while.
B/ Discourage in-fighting with +ve reinforcement instead of -ve. Every time two or more teams come together to ship a major feature, recognise that achievement publicly with fan-fare. This seems to be working quite well already.
C/ Be more careful while discussing major org changes and announce within a few days of the decision such that there is no hanging uncertainty

I have two more learnings but this blog is already running too long and I’ll probably publish these two as a second post next week.

3. Predictability as a leadership trait is seriously under-rated

4. Becoming religious about writing down thoughts

Just a final parting note, realizing my mistakes and even knowing a solution to a problem is one thing. Implementing that solution is a whole different ballgame and I realize that is where I mess up most often. Hope to not repeat a few of these mistakes going forward.