Vikrant Payal

Innovation

An organization's appetite for failure is one of the best measures of how much real innovation is happening inside it.

NVIDIA, Microsoft, OpenAI, Tesla have all run huge bills on failed starts. Compare that to other large companies that appear to be scared to fail - Intel, Apple, Google, Ford. A culture where innovation is projected as an important 'goal' eventually starts treating innovation as a thing to be measured, tracked, reported. Bundled with other measures, trackers and reports, a failed innovation attempt sticks out and makes the management chain look bad. Naturally attempts to try any radically new approach are discouraged - 'what if we fail?'. Updates transmitted up the chain are watered down or reworded to create an appearance of progress or success. This creates a spiral of imposed positivity which slowly drains the spontaneous energy that generates true innovative solutions.

jul'24

Measuring Success

Does your leaderboard measure effort or outcomes?

The start of any new initiative or project is marked by optimism and the energy to show quick results. Naturally reports designed to check 'are we making progress' focus on individual, mini-tasks. These could be backlog development, feature designs, wireframes, workflows to be automated, environments being built. None of these are outcomes. These are steps that should lead to outcomes in an ideal world. Just a few weeks in, reports find roots in the weekly routine, especially in organizations that depend on people for reporting. People form habits. They also develop lethargy towards change.

A report that is very relevant during 'take-off' is misleading when it is time to check progress and direction.

Ideally leaderboards, dashboards, recurring reports should be taken back to the drawing board when they look similar across weeks. They should be refactored to talk about how close we are to a goal, instead of how much work was done. People avoid doing this. There is a satiated feel to seeing reports that say - all ok, nothing to see here. This is easy to do when the report structure expects progress updates. This mechanism does not help the leader catch what is not being said. It does not talk about if we are where we should be. Nor if there are inefficiencies building in the workflow.

jul'24

Methodologies Age

The age of new methodologies, practices, collaboration frameworks in tech is coming to an end.

These were crutches to help overcome weaknesses in us, humans. Can't deal with complexity? Break it down and iterate with Agile/Scrum/Kanban/PMP. Panic and confusion in production? Let's put some structure with ITIL/COBIT/SRE. We have petabytes of material, centuries of recorded trainings and whole careers built studying and exercising these prescriptive practices. They were all developed with a few common assumption.

Assumption #1 : Building and maintaining large software products and services will continue to be complex, difficult and time consuming.
Assumption #2 : Bigger, more complex projects will need more people.
Assumption #3 : Only people have the depth, perception and imagination to bring structure to chaos and herd a large mass of other people.

Each of these assumptions is wrong today. You can potentially build better software products faster with fewer people and fewer interruption by framework champions. GPTs are helping structure thought and organize work. Coding agents are helping build software at the speed of thought (shoutout to Cursor). Once the cost and security of AI reach maturity, we should see more advanced tools managing the complexity, data density, integration and people collaboration across large software projects. The basic tenets of these methodologies and frameworks will continue to be relevant, but the arc will lean towards using common sense and great tools rather than depending on strict adherence to pre-defined workflows and processes.

2030 software development will still be human driven, but there will likely be less need for dedicated, certified framework champions herding developers and support engineers.

sep'24

Courage as a leadership characteristic

Showing courage is an underrated skill in the must-have skill inventory for leaders. Empathy, ability to listen, communicate effectively, strategic vision get a leg up over courage. The real test of a leader is in choppy waters, not in calm seas.

Some of the most effective leaders I worked with had the courage to ask difficult questions. A typical business day presents many scenarios where leaders cannot shy away from giving tough feedback. There are so many lost opportunities to do what's right for business, lost to a leader who cannot speak up against a miscalculated decision because it came from 'higher up'. Mid to senior leaders who have the courage to give bad news clearly build trust with their stakeholders. The list goes on..

Yet this vital skill rarely receives a mention when grooming the leaders for tomorrow.

dec '24

My values at work

Through the two decades of my work experience, these values have helped me the most. I live by them and encourage my teams to adopt them.

Exhibit a sense of urgency. Be responsive. Deliver with speed (speed first, perfection second).
Solve problems. Always be clear on what problem you are solving for the company.
Create real value for the end customer. The value generated should be proportionate to or greater than the cost of generating the value.
Work as a team. Do not silo work/knowledge/communications. Pitch in without hesitation. Share widely.
Results matter more than effort. Avoid the complicated approaches and solutions as best as possible. Deliver quick results instead. Reuse, don't reinvent.
Communicate frequently and effectively. Overcommunication is okay, under-communication is not.
Respect everyone in the team. Conflicts, difference of opinions, arguments are okay. Communicate with civility and genuine respect.
Learn constantly. Focus on applied learning (not just certificates).
Aim high, deliver consistently.
Work towards a clear personal growth plan.
Take pride in everything you do. Our work should have our signature on it. Make it reflect quality, depth of thought, engineering excellence and user delight.

feb '25

How to AI?

"How can we add AI to this?"

A question many leaders across domains are asking themselves and their teams. It is not necessarily a bad question - as long as it comes second, after "Why do we need AI for this?"

This is not a pessimistic take on AI but a necessary filter to avoid implementations that earn the AI sticker yet fail on value, ROI, and speed-of-delivery KPIs.

An agentic approach and well-designed prediction models, when applied with business impact in mind, unlock the ability to scale fast. Putting vast datasets at employees' or business users' fingertips through LLMs can transform how they interact with applications. AI can also automate micro-decisions, accelerating workflows in ways that were not previously possible.

But unless the Why has a solid answer, the How leads to distractions and AI hype-driven development. Building an LLM chatbot is easy - college students do it. The real test lies in cost, scalability, data management, and the relevance of its results.

Why before How. Always.

feb '25

AI in India

Very good thoughts on how to leverage AI for India effectively

Link

apr '25