Prasad is a builder-at-heart, and writes about product management, leadership and coaching talent. He's equally passionate about family, food & travel.
I am not a huge fan of LinkedIn’s cover image. Its an odd-sized banner that gets overridden by ads and the profile header itself. The flip-side of not having one is that it makes your profile look very lame. After all, a picture is worth a thousand words.
A couple of iterations later, I put up a metaphor of my professional side as the cover image. What do you make out of it? I’d love to hear in the comments section.
My LinkedIn Cover Image (Mar 2015) – Click to enlarge
Business travel is very boring. But along the way, you need to find ways to keep it exciting. Haynes introduced me to FlightDiary which has helped me keep track of travel and analyze it. Day before, I took my 100th flight via Mumbai from a total of 170. Here is how my flight-diary looks now:
a.k.a. Why & How Product Managers must assess, account & groom technical debt
Context
Technical Debt explained (c) galorath.com
When I started conceptualizing a new product 5 years back, the concept of technical debt only existed in theory. Over a period, the pressure of time & customers, drove features cuts, compromises, and unfortunately, some quick-and-dirty solutions. Post the short-term wins, its not too long before technical debt surfaces and forces a resolution.
Triggers
Technical debt is taken up for short-term advantages such as shorter time-to-market, and preserving capital. But in the long run, it reduces productivity, time available for new feature development and, God forbid, might keep you from crossing the chasm.
While Product Managers balance out the short and long term benefits/impact of every product decision, it is important that they keep track of the debt that is being baked in with every story. At the same time, having some framework to preempt the debt that is inadvertently introduced and proactively manage it as a roadmap item.
The Debt Assessment Framework
Fowler categorizes debt as Reckless v/s Prudent, or Deliberate v/s Inadvertent. While this classification answers the ‘how’, it doesn’t provide visibility into ‘what’ and ‘where’ of debt is added. Without further classification, accounting debt is like having a balance sheet with just one account for liabilities. I would like to further categorize all the debt that is deliberately added and assess its risk upfront. Here’s how:
Risk assessment for (deliberate) technical debt
Type
Potentially lacks..
User Visible
Sales Risk
Ops Risk
Business value
Comprehensiveness in all business scenarios, Browser/Language support, Super admin rights, etc.
Y
Y
N
User Experience
Simple task flows, help cues, consistent design, mobility, Usability or A/B testing
Y
Y
N
Performance
Quick response, High availability, Clustering, CDN, Load/Stress test suite
Y
Y
Y
Maintainability
Data redundancy, Recovery, Migration, Configuration management, Sizing estimates, Documentation
N
N
Y
Design/Architectural
Portability, Modularity, Coding standards, & styles, Web services, Latest component versions; Has glue or duplicate code
N
Y
Y
Test Automation
Comprehensive coverage of functional/unit tests, either brittle or missing
N
N
Y
If you’re wondering why (missing) features and defects don’t show in the list, that’s because they are the fundamental work units for development and not actually debt.
I only have one planned vacation each year – a trip to my native place Murud-Janjira. It is a coastal town in the Raigad district of Maharashtra, about 160km from Mumbai. My grandfather left Murud to attend law school in Mumbai. 3 generations later, there is still one thing that keeps the extended family together and coming back to our native place – our temple.
Janjira Fort, Murud-Janjira
A couple of centuries back, one Mr.Joshi had a dream about an idol of Lord Ganesha under a tree. They dug it up and indeed found a stone resembling in shape with a Ganesha idol. It was then handed over to our family to be worshiped. What must’ve started as a small shade in Nandgaon (10 kms short of Murud), is today a popular destination for devotees & tourists alike.
Love is.. when food choices are diametrically opposite
Every relation demands trade-off & adjustment. It is nearly impossible to find harmony in all choices. Aditi & I also took a hit on compatibility in some areas – food was one. I am a complete foodie, and she’s a great cook. I love chicken & chapattis, while she loves fish & rice. But when I cook, I try to make things that will go past her choices. Like all kids who hate plain chapattis, she loved the variation of baked rolls with chicken, cheese & veggies.
Ingredients:
2 onions, sliced
1 green capsicum, chopped
1 tomato, chopped
3 garlic cloves
Tomato ketchup
Chilli powder
Oregano
Chat masala
Salt, to taste
Butter
6 Chicken tandoori kebabs (or shredded chicken) – or replace with cottage cheese (paneer) for a veggie version
4 chapattis
Cheese – grated mozzarella & slices for topping
Procedure:
Vegetable stuffing
Heat some butter in a pan, and place garlic cloves
Add all vegetables, tomato ketchup and salt to taste
Saute vegetables until cooked
Key ingredients
Assembling the rolls
Butter both sides of each chapatti
Place the vegetable stuffing at the center, and top with chicken or paneer
Grate mozzarella cheese, sprinkle oregano/chat masala to taste
Roll ’em up, and place cheese slices on top for an extra cheesy taste
After a lot of reading & thinking, I came up with the idea of a simple Trello board to help me conduct effective one-on-one meetings with my team, and to plan each team member’s growth. This is the boilerplate that I could quickly replicate for each team member using Trello’s “Copy Board…” feature. My team has been using it since last October and they’ve found it really helpful to communicate their achievements, issues and most importantly, to plan their growth.
Thanks to them, its now mature enough to help other managers better engage with their teams. The boilerplate board is now public so you can easily copy & build on top of it. Here is a sample board showing real-world use. Get started by copying the boilerplate, and let me know how it works or how we can improve it.
My one-on-one pattern has greatly evolved over the last 4 years that I’ve managed teams. Starting naively by tracking work, it now leaves the daily stuff out and instead focuses on the individual itself. When my travel increased, I felt the need for something online to retain the connect. I believe in transparency and I hate secret dossiers; I wanted a platform where we both have the same view of the relationship, which becomes the single version of truth for all discussion. Also, since it was their plan, I wanted my team to have access even when they decide to move on.
I’ve got inspiration from a lot of sources: blogs, surveys & talks I’ve participated in, etc. Thanks to all!