And Vijay Says…

So I turned 42 – and woke up to 100s of birthday wishes from family and friends around the world. Its also the first time I have had my parents and my mother in law with us here for my birthday, and that makes it extra special.

As I settled down with my two fur kids to enjoy a cup of coffee, it dawned on me that 42 is my favorite number – thanks to Douglas Adams . When I first read the book, I had my fair share of theories (and fierce arguments with friends and strangers) on why is it the ultimate answer – including the binary representation and all.

Then I found out the truth a few years ago and then I liked 42 even more!

“The answer to this is very simple,” Adams said. “It was a joke. It had to be a number, an ordinary, smallish number, and I chose that one. Binary representations, base 13, Tibetan monks are all complete nonsense. I sat on my desk, stared in to the garden and thought 42 will do. I typed it out. End of story.”

The big lesson that 42 taught me was to not take the world around me – and myself – not too seriously . When we do take ourselves too seriously, the joke is invariably on us 🙂

There are three times every year that I look back and forward – New year, my birthday, and the day I review the business plan for my team at work.

Looking back, its amazing how perspectives change with time – and some times at alarmingly accelerated pace. Some totally random birthday thoughts here.

1. Growing old is not some kind of slow process – and not something that only happens to others. When I joined TCS out of B School, I was 24 and my boss was 30. We used to call him “The old man”. Joke is on me – I am the old man now 🙂
2. Not everything that is forced on you is bad. I hated being sent to learn Carnatic music as a kid. I never became a good singer, but the music theory stayed with me and now I appreciate the music a lot. I still tease my mom for forcing me to learn music and she teases me that all I seem to listen to is the music she forced me to learn. The irony is readily apparent to me as I drive my kiddo to her weekend activities, some of which she thinks we force on her 🙂
3. All I wanted as a young kid was to become a professional dog handler. I was pretty good at the craft – and had my fair share of wins in the ring. I still enjoy dog shows – but I enjoy spoiling my fur kids at home a lot more today than taking them through their paces at a show. From time to time I do feel the urge to take the leash and go into the ring just for fun – and I might still do that one of these days. I am not yet fully over the grief of losing my dear fur kid, Boss, but I am also convinced we will get a pup again in near future.
4. Life has a way of going in circles. After a degree in mechanical engineering and an MBA, I decided my calling was as a programmer. Then along the way, I got nudged into sales, management and all that I hated as a young developer. Turns out not all sellers and managers are horrible people like I initially thought 🙂 . And guess what – its my technical skills that help me the most as I build my current team.
5. While I try hard to keep my tech skills sharp, I have also realized that its way more fulfilling to be the one handing out the prizes than being the one gunning for those prizes. Bar none, the best part of my work life is to help my friends and colleagues succeed and be their number one cheer leader. And on personal front, the (more than) equivalent is being the chief cheerleader for my daughter.
6. I (think I) always knew that life is way too short to spend on unimportant things. What I did not realize very well till recently is that some (previously) small little things have become more important to me over time and some big ticket items from past don’t figure in my top priorities as much any more. I just need a little more conviction to say NO to weekend work phone calls – but I am planning on getting better at this really quick 🙂

 

Project management is hard as it is . There are three aspects of project management that I think need some extra attention when the project is about AI . Pro tip – if it’s your first time , consider buying a Costco membership for the BIG aspirin containers 🙂

The three aspects ( certainly not the only three) are

1. Estimation 

2. Change management 

3. Testing

It’s the very nature of AI based development that makes it harder than traditional project management . Let’s start by making a few assumptions 

Good engineers who can work well with AI are hard to find – but for this discussion I am going to assume skills are not an issue and somehow the PM formed a team with all the right skills. 

Since AI functionality is exposed as APIs in many cases , I will also make another “simplistic” assumption to make my point about PM that engineers don’t need to be big time mathematicians and statiticians to use the available APIs .  

Just so we are clear – you do need great skills , and you do need some experience with the math to do AI projects well . I am just making these assumptions to keep the focus on PM in this post . For good measure – I am going to use waterfall language here, but there is no difference if the project uses Agile 

Let’s start with estimation . The first step of the process is to define phases like say development and testing , and use some historical data to figure how much effort and time it takes . This is easy for many parts of development like web/mobile/DB etc since there are plenty of past projects to give realistic guidelines . Then we get to the AI part – let’s say just one model is in scope that uses Machine learning .

Now we run into the first issue – whether the model we chose is the right one for the app we are building . In many cases – we won’t know till we actually test it . And even if it works ok , it might not be valuable enough of an insight that it throws back to the app . So whatever we estimate – there is a good chance that while developing we will need to switch drastically to something else and that will invalidate prior estimates . This is on top of all the other things that can go wrong in the actual design of the app . 

Even if the model technically works – performance can become a dog . Not all models support parallel processing . In many cases , another statistical method might need to be considered after you realize performance is going to be a problem . Ergo – potential to rework is lurking throughout .

Then there is the second issue – which is that unlike traditional projects , source data can fundamentally change the fate of an AI project . Data is already a problem in traditional projects  – unclean data can increase ETL effort for example . But it’s kind of easy to estimate ETL effort after you profile source data . But even if data is technically clean – your model may not find it useful . You probably will miss data you need , or need data from additional sources and so on . And there is no good way to know this prior to putting the data through your model . It’s also not uncommon for your base application to change its paramarters significantly because your model needs different information eventually than what you originally designed . 

In other words – your dev and testing team can drive you nuts if you walk in as PM with “traditional” expectations. Now to be fair – it’s not because your engineers are willfully . They just have a harder time debugging when things go sideways – and a lot of things go sideways . The Costco membership helps with less expensive beer over weekends where you reflect your career choices  🙂

These two issues already make it hard to estimate and test an AI project . Now let’s look briefly at the change management aspect . 

Explaining what an ML model does in business terms is a non trivial challenge to begin with . Now to explain why the model doesn’t work as planned and why it needs to be reworked – without guarantees it will work the next time – makes it a much harder problem . Even when things work well – and if a business person asked you to explain why the model arrived at the result it did , its often hard to explain .

Good PMs educate their stake holders – AI projects can make them look like a tenured college professor 🙂 

So how does a PM mitigate these issues ? I will offer a few thoughts 

1. Start by educating yourself on fundamentals of AI . You can even create little chatbots etc with minimal to no coding . Get a feel for the actual work upfront before you take over the project . Make sure all your non technical people like Business Analysts do this too 

2. Set the expectation with the client on the nature of the AI projects before the project starts . You can do this with real examples using simple models that you can mock up in Excel and then help the client extrapolate what will happen if something goes wrong 

3. Insist on highest quality engineers . If you have to develop something from scratch today – developers need experience with multiple frameworks and know their trade offs . AI models add a layer of complexity on top and have their own trade offs . Having past experience won’t eliminate all the issues I called out – but it will help minimize the mistakes , and when things go wrong you will recover faster . 

4. Aim small , Miss small . Try hard to resist the temptation of trying to build a complex system in one go. Make small goals and course correct as you go . 

5. Double down on data quality . Encourage your ETL team and data scientists to keep looking at data , visualize them differently and identify problems as early as possible . 

6. Create a support system for you and your team . It’s a new field and everyone needs help from time to time . If you don’t plant your shade trees up front , you will face nothing but grief later 

I am very curious to hear your thoughts and comments !

The general idea of feedback in the context of management and leadership is like motherhood and apple pie. Feedback is good and without it, it is hard to improve. But that does not mean that we are good at giving and/or taking feedback .

Feedback becomes necessary mostly because, hard as we all try – it is really hard to be perfectly honest with ourselves to take corrective action in a time frame that matters. I am in my forties now – and I am perfectly honest about stuff that happened in my teens and twenties. I work hard on fixing some of those “issues” . I cannot say with similar conviction that I am honest about my strengths and weaknesses when I think about say the last 5 years. For that, I need to hear it from others.

People tend to underestimate or overestimate themselves. It is a lot easier to judge someone else ( and also say “who are you to judge me” )  🙂 On the work front – I have had very few managers who have consistently given me useful feedback . People ask me for professional guidance all the time too – and I am sure some of them think I suck at giving useful feedback as well.

Most feedback is pretty useless – generic questions get asked and generic answers are given. My two favorite examples of thoroughly useless feedback from managers to employees are

1. You need to improve your communication issues ( probably present in 90% of all performance appraisals for people in their first ten years at work)

2. You are doing great – keep doing what you are doing and good things will happen to you. ( Run, don’t walk – this comes from lazy managers who have no idea about your work or what they can do to help you get to the next level )

If you only seek or give feedback in long intervals of time, its generic nature is more or less guaranteed. A continuous process – can I make up a term “micro feedback” ? – is a lot more valuable. But for this to work – a few things need to fall in place

1. For feedback to work – there needs to be mutual trust. And trust takes time. So don’t expect consistent overnight results.
2. Aim small, miss small. Having a road map to your destination and being pragmatic about diversions along the way makes giving and receiving feedback a whole lot more valuable. Specific feedback is a whole lot easier if your goals are specific. I will go on to suggest – perhaps the most useful feedback you can get is to keep validating whether your roadmap itself is useful anymore, compared to just validating individual goals.
3. Person getting feedback needs to know that ultimate responsibility of acting on feedback is with them, and not the giver. Its your life and career – no one will take care of it like you !
4. Person giving the feedback should be comfortable in making the feedback specific or say clearly that they don’t have any good ideas this time. Ideally make introductions to someone else who can help if appropriate
5. Person asking for feedback should resist the urge to defend themselves to the extent they can. By all means ask clarifying questions though to understand the perspective that is offered to you. As I heard in the Netflix series “The crown” where the Queen mother tells Queen Elizabeth “It takes every ounce of energy not to say or do anything” 🙂 . I know – I have bit my tongue a lot when I have heard candid feedback, and almost every single time it has helped me realize how I was fooling myself.
6. Rather than defend, I prefer asking for feedback from multiple people and look at it as holistically as you can. If you ask only one person all the time – you are just inheriting their bias. One way that has worked for me in the past is to ask someone close to what I do for feedback ( lets say my immediate manager) , and another one who I know has experience in what I do ( say a senior executive in another company or another part of my company).
7. If you decide to not follow the advice you got – try to explain it to the person whom you got feedback from. This is best done if you both set up expectations upfront. This is harder than it sounds – but if you don’t do this, there is no sense in asking the same person again. They will tune out at some point. Over time, my own way of asking for feedback is to create a set of options and ask for advice on which one I should choose and why. I am always open to a new option that I might get from this exercise.
8. While persevering at something is laudable – the pragmatic way to look at it is that not everyone is good at everything. If after receiving feedback and acting on it for a while does not seem to make you good at it – you absolutely should question both the source of feedback, as well as your own ability to improve.
9. Always have a realistic plan B. Not all ideas pan out even if you do all the right things (including acting on feedback). If you don’t have a plan B, you are bound to be driven by fear of failure and that is not always a good motivator. Best time to develop a plan B is when plan A is working well.
10. Never be afraid to have a strong point of view. Your ability and necessity to take feedback should not be confused with the need to have your own strong opinions. Just be willing to stand corrected