The last post was about what to avoid, this post is about what you can do to make a migration successful.
Sequencing is key
With any large initiative, the natural impulse is to throw a lot of people at it. Avoid this impulse at all costs. At the beginning of the project, it is better to have a small team of your crack developers and senior engineers and PM’s to focus on building a skeleton of what the end state would be like.
I’ve always been interested in figuring out what signifies greatness in PM, what makes a great PM?
A source of signal for me has been the ability to deal with ambiguity. Great PMs have this innate ability to take ambiguous thoughts/ideas/strategies as input and come up with a coherent executable plan which then they execute ruthlessly. A great PM has the superpower of bringing clarity to everything.
The anti-pattern I’d like to explore today is what I affectionally call the head of problemaka senior’itis. In my experience, this is the factor in org design that increases burn and bureaucracy. This anti-pattern is lethal for companies.
It starts off quite innocently. Let’s assume you are the CEO at the early stages of a company and you have identified a problem to solve, say in the general area of customer support. Customer support as a function doesn’t exist yet. You ask around your peer group, you look at successful companies and then you make the common mistake – you get afflicted by senior’itis. You decide that you need somebody senior to run that function, you need somebody who has done it before somebody with pedigree. You need a Head of customer support. You then spend a lot of time trying to woo the right candidate, the one that checks all the boxes. You hire him after a long drawn out courtship. You are happy, your customer support problem will be solved, you have found the right person. You have hired a person who will take accountability to solve the problem.
The next few posts are going to be about anti-patterns. These are all about the landmines you should try to avoid – learn from my mistakes :). Almost all problems in companies are people/organizational problems. Hopefully, these set of posts can help you navigate through some of the nuanced ones.
Imagine the scene, its the end of the day, dinner is done, you are ready to turn in. The last thing you have to do is wash the dishes. Your spouse loads the dishwasher and just as she is heading to bed, she tells you “Honey put the soap in the dishwasher and turn the dishwasher on”
Global, distributed teams are everywhere. Companies expand beyond their home country to grow their business and/or find talent. Pretty soon you are managing a global team and your managers are all over the globe. How do you cope? How do you scale yourself and your team? How do you keep in touch?
Accountability is a fascinating topic. The textbook definition is “the quality or state of being accountable; especially: an obligation or willingness to accept responsibility or to account for one’s actions”. While a lot has been written about individuals, I’ve found in my experience, the actual mechanics of how to think about team accountability for product teams, pretty lacking. This post is an attempt to describe the framework that has been useful for me. A few of these tips are borrowed from the great executives I’ve had the pleasure to work with and a few are homegrown. Hopefully, this helps somebody who is just starting out or well into their manager/team leader journey.