Zingography #12 : It’s All About Loving Your APIs

Total Surrender to the API Culture is the New Thing especially in the space of payments for easier merchant integration, easier SME solutions of businesses (Invoicing, Salary Payout, Disbursements), easier Future Tech adaptations (SaaS Tools Integrations), more convenient Payment Use Cases Integration.

The quality & quantity of efforts being dedicated towards Payments APIs shall decide the success of that Payments Platform.

The Stages across which an API Development goes through comprises of below :

  1. Brainstorm – First, it is necessary to identify key services your business offers and capabilities of the business. Figure out the kinds of APIs that should be built and which services should be offered via APIs. Also, figure out and write down the use cases for each API. Write down potential endpoints based on those use cases.
  2. Establish API stakeholders – Who are the stakeholders within your organisation? As many people as possible should be involved in your API initiative – you need company-wide buy-in and a vision that is shared by teams within your organisation. Also, allow stakeholders to weigh in on the design of the API. Stakeholders can then agree on interactions across the organisation so that APIs remain consistent.
  3. Design an API contract – The contract establishes a set of standards and best practices for designing APIs. Be sure to describe and document all APIs. Ensure that all APIs work the same, from endpoint names and URLs to error codes and versioning. Consistency is key.
  4. Create a style guide – A comprehensive, cohesive style guide ensures consistency across the teams of an organisation who are building services. API status codes, versioning, error handling, and more will be standardised ensuring that APIs are designed the same way. Use a tool like SwaggerHub to create a style guide for all APIs across your organisation.
  5. Implement API governance – An API governance process can help enforce established standards and reinforce desired outcomes. We discuss API governance in an upcoming blog article. Conducting peer code reviews can also help ensure that API design standards are followed and that developers are producing quality code.
  6. Automate processes – Use tools like SwaggerHub to automate processes like generating API documentation, style validation, API mocking, and versioning. Also, make APIs self-service so that developers can get started building apps with your APIs right away. Provide interactive documentation or a sandbox so that developers can try out API endpoints.
  7. Track and manage your API portfolio – Avoid duplicating code and building redundant APIs by tracking and managing your API portfolio. Implement a system that helps you track and manage your APIs. The larger your organization and platform becomes, the harder it gets to track APIs and their dependencies.
  8. Create a portal for internal developers – Create a central place for internal developers, a place where everything for all your APIs is stored- API specification, documentation, contracts, etc. For example, PayPal has built a portal for its developers and it’s “one of the most visited internal apps in PayPal,” according to an InfoQ article. PayPal’s portal includes an inventory of all APIs, documentation, dashboards, and more.

 

This slideshow requires JavaScript.

Key Takeaways

  • Implementing an API-first transformation in a large organization is as much a people problem as a technical one
  • Organizational chutzpah will strongly influence your API-first success strategy
  • Treating the transformation itself as a product promotes long term success
  • Process and governance are necessary, but keep it light and make it work for your customers
  • Don’t underestimate the investment in tools, infrastructure, and people required to make it work

Getting Your API Strategy on

It wasn’t that long ago the idea of exposing your core plumbing externally was verboten. The real products were the apps and experiences you built on top of that internal stuff. Most product investments resulted in vertically integrated solutions that served a relatively limited set of functionality. Leveraging that investment for a totally different set of use cases or a different product line was often somewhere between difficult and impossible. In that context, it was natural to think of the underlying infrastructure as sunk cost or internal-only plumbing. It was hard to imagine it differently.

That’s changed. More or less every company now has an API strategy that strives to leverage a much larger portion of its technology investment by exposing the outcome in the form of reusable services. The high-level goal is to accelerate business agility by making core business capabilities easily accessible and reusable. Reducing the cost of integration not only has a positive impact on internal velocity, it also provides for increased flexibility and speed incorporating customers, partners, and acquisitions. The days of monolithic, vertically aligned mudballs are rapidly coming to the end. What’s now generically referred to as “microservices,” exposed via nicely designed and documented APIs, with a clear bounded context and semantically distinct business value are where we’re going.

The API Economy

Why the change? The emergence of the API economy has changed the rules.

Some of the highest value companies in the world – Facebook, Google, Amazon – all figured out a while ago that opening the kimono and providing external developer access to more of the plumbing of their core products was a great way to leverage their tech investment, reinforce their product portfolio, and expand partnership opportunities. They built cultures that reinforced share and re-use principles, which were key to making this possible. This catalyzed the API economy and enabled many, many new products to be built and market-tested faster and more cheaply than before. API providers reaped the benefits of more customers, more traffic, deeper integration, and, at least for some, the seeds of new, multi-billion dollar businesses. Even Twitter owes much of its early success to an API strategy even if they subsequently pulled back from it.

The second wave – companies like Twilio and Stripe – skipped the traditional “product” part altogether. They made the APIs themselves their core product and focused on providing great developer experiences as their primary mission. Their customers quickly integrated and got the benefit of essential, needed capabilities without having to build and maintain a lot of non-differentiating functionality themselves. Agility improved. Hackathons happened. Apps and start-ups exploded. It became the default way to build new experiences, iterate, and verify product-market fit.

To remain competitive as an established player your organisation also needs to adopt an API-first approach.  It is a nontrivial change to how you look and think about your tech portfolio.

Actualising Your Future

For newer companies, this approach is already second nature. They’ve likely grown up inside the new reality. But what if you are a large, established company with a lot of existing infrastructure and customers? How do you go about making this transition while still running your business?

First, your tech landscape probably looks quite different. Your legacy code base – probably influenced by SOA, but developed before “microservices” was even a word – is likely sub-optimal. You may have built a lot of tech debt over the years and you may not have a culture that natively reinforces the principles of clear componentization and reuse. Testing may be spotty and there are likely skeletons left over from various re-orgs and abandoned projects. Documentation may leave a lot to be desired. This is not a nice, level foundation on which to start a major microservices transformation. There are, as we say, a lot of “challenges”.

The other major consideration is organizational chutzpah. Executives may be sold on the need for an API-first strategy, but their understanding of the commitment required to get there may vary. Understanding where you are on this spectrum is very important to your success.

On one end, you get the Manhattan project. The bus stops, everybody gets 100% with the program, it’s the top priority, and almost everything else is put on hold. This is rare. If you find yourself in this situation, run with it. Treat it as a massive project and move quickly. You’re not likely to get a second chance.

More likely, practical reality puts you somewhere in the middle. There may be a commitment to slow the bus a little, but it’s definitely going to keep moving and the wheels will need to be changed along the way. As a leader of the transformation, this feels a lot messier. It raises a lot of difficult and important questions that don’t have obvious answers. How is it going to be prioritized? Which teams are going to do it? How is it going to be coordinated? When will it be done? Your job just got a lot more complex. It’s no longer a project. It’s now a complex transformation that may continue for years and it’s as much about organizational change as it is about a technology transformation.

Put on Your Product Hat

At PayPal, we’ve been on this journey for over three years. We’ve used a customer-oriented approach to go from a very monolithic, siloed architecture to a much more loosely coupled set of over 150 services with well designed, modern APIs.

There is a tendency to treat programs like this as engineering projects. We didn’t. Instead, we framed this as a larger, organizational change problem with the “product” being a fundamental shift in how we design and build APIs. Viewed that way, we were forced to identify and serve all key “customers” – developers who build and consume APIs as well as the executives that support them. It shaped our strategy, the tooling we built, how we communicated, and how we measured success. Identifying your customers and focusing on their satisfaction is a fundamental product principle. This mindset has been key to our success and it continues to shape how we manage the program today.

While no two companies are the same, many of the lessons we’ve learned and approaches we’ve used are applicable to other organizations on the same path.

To break this down, we’ve organized the effort using a framework we call the “3P’s”.

  • Product – the infrastructure, standards, and tools used to manage the portfolio of APIs and underlying service implementations
  • Portfolio – the catalog of business capabilities, represented as APIs and underlying services
  • Program – the metrics, training, and levers used to incent changes in organisational behaviour and technology investment

This article is the first of three that explores these dimensions in more detail.

Product

In a small company of a few dozen to maybe 50 or 60 developers, it’s not that hard for the key stakeholders to get in a room, hash out a plan on a whiteboard, divide responsibility, and get to work. There will be a pretty good, shared understanding of the plan and goals, and, after some iteration and course correction, you’ll likely end up with a nicely integrated and cohesive set of APIs and underlying services representing your platform. Your timeline is probably represented in months, or maybe quarters.

In a large organization, things are different. You may have hundreds or thousands of developers spread across multiple business units and geographies, all with differing objectives and, often, different tech stacks. For many reasons, not the least of which is Dunbar’s number – you will not have a Kumbaya moment where everybody holds hands, agrees on the goal, and gets to work. What you need is something more distributed, more scalable, something that reinforces your objectives without depending upon the frailty of social contracts or large scale project coordination. In this context, the “Product” is actually the infrastructure that supports the transformation (not the APIs themselves). This is a significant investment in and of itself. At a minimum, it should probably include the following:

  • A playbook defining common principles and standards for APIs
  • An engagement process to ensure compliance when developing APIs
  • A means of governance including clear and objective measurement
  • Some kind of centralized portal to consolidate APIs and manage the process and metrics

Principles and Standards

At PayPal, we started off thinking about what common ideas would guide us towards our goal of nicely encapsulated services that exposed well-designed, reusable APIs. These became our core principles and they framed much our subsequent standards documentation.

  • Loose Coupling – Services and consumers must be loosely coupled from each other.
  • Encapsulation – A domain service can access data and functionality it does not own through other service contracts only.
  • Stability – Service contracts must be long-lived with a predictable lifecycle.
  • Reusable – Services must be developed to be reusable across multiple contexts and by multiple consumers.
  • Contract-Based – Functionality and data must only be exposed through standardized service contracts.
  • Consistency – Services must follow a common set of rules, interaction styles, vocabulary and shared types.
  • Ease-of-Use – Services must be easy to use and composable by consumers.
  • Externalizable – Services must be designed so that the functionality they provide is easily externalizable.

Setting The API Structure within Organisation :

Step 1: Understand Your API’s purpose

What problem does your API offering promise to solve? Having an outcome-driven approach to API development can help you define better metrics of success, build a sustainable and scalable development strategy, and facilitate faster stakeholder buy-in. Some famous use-cases for APIs include:

  • Facilitating faster development and creating an adaptable architecture by exposing all internal services via APIs – Amazon
  • Creating a successful platform to drive higher engagement of users – Facebook
  • Grow traffic to main website by incentivizing sending users through a partner API model – eBay

It’s important to fully understand the purpose of your API to see how it maps into your business taxonomy. This taxonomy is composed of smaller building blocks of your business from a functional stance. Identifying this, and defining the problem space of your API, helps provide a more focused approach to conceptualizing the exact purpose of your API, and how it maps into your existing business.

Step 2: Understand Your API’s Audience

It’s easy to throw the word “developer” around. What’s important to understand is what outcome the end developer is trying to achieve, and what domain they are in. There can be two consumers for your APIs:

  • Consumers in your direct vertical: This type of API consumer builds services that directly benefit the main consumer of your core product.

For example, Slack’s end users are people within a company trying to communicate better with each other. To better facilitate collaboration and communication, Slack’s API can easily integrate with many popular third party tools that companies use and centralize notifications received from these tools. This way, Slack’s API can directly benefit the same people who use their tools and drive higher engagement and value.

  • Consumers in tangential verticals: This type of API consumer would build services that may not necessarily help the direct consumer of the product, but solves the need of another vertical.

For example, ride sharing companies like Uber could integrate with the Yelp API to give suggestions for good restaurants depending on the location their passengers are driving through. This is a classic example where Yelp’s API is benefitting the consumers of Uber, a company that can’t necessarily be considered as Yelp’s direct consumer. In general, this allows you to have the vision of your full API value chain, made up of your API’s direct and indirect consumers.

Step 3: Align your Team

A successful, scalable API program first needs a solid team behind it that’s fully aware of the API’s objectives and purpose. A great team starts with alignment. The belief that APIs are products, that they solve problems, and they have customers who care about quality, is a mindset that needs to be instilled among all of your teams. A culture of digital transformation involves full buy-in on the power of APIs to be the foundation of a successful platform.

Alignment can come when you clearly articulate the current and future state of your APIs, and how they tie into your entire business strategy. After this, figure out how you tie all of your development, operations, and marketing teams together though well-defined processes.

The way you choose the right people, and define processes that keep them and their workflow intact, can be a determining factor in the success of your API programs. You should also implement tooling that supports a collaborative approach to API development.

Step 4: Develop your API Incrementally

Having a product driven approach involves building APIs that provide immense value to your consumers. A proven tactic to delivering APIs that people love is the build-measure-learn philosophy. This is taken directly from the Lean Startup methodology of having a set of assumptions around the validity of your offering, and iteratively proving and disproving these assumptions. APIs are built incrementally, with regular stakeholder and customer feedback in every iteration, to eventually deliver a great API.

We can divide development into all of its individual life-cycle phases. It’s to be noted that all of these phases should be supported by good tooling infrastructure that align with your company’s culture, methodologies and practices. Tools like SwaggerHubApiary and Reprezen can help development teams design and build APIs in a collaborative environment.

Designing the API

At the end of the day, your API is just a contract between a server and client, with the request-response cycle acting as the terms of the contact. If your end consumers are the ones finding value from your API, this contract needs to be designed with their needs in mind. Designing an API means providing an effective interface that helps your internal stakeholders aligned on the API’s request-response cycles, and external consumers better understand, use, and integrate with the API.

Design is the step before you develop your technological artifacts and business logic. The design of the API acts as the forcing function to really put your API objectives and persona targeting into a human and machine-readable document for your executives and technical teams to consume. As a product management technique, this is an easy way to also focus on the consumer, designing an experience that caters to the type of audience your API is marketed towards.

In the REST ecosystem, the OpenAPI Specification (OAS) has emerged as the world’s standard for designing the interface. The OAS is a human and machine readable specification that’s language agnostic. It’s currently in its third version, with rich expressive capabilities for new security definitions, call backs, linking and more. The API’s definition in the OAS also opens up a world of possibilities in the form of mocking, generating server stubs, SDKs, test cases, and more.

For more visit our API Design Insights page

Virtualising the API’s Dependencies

Your API is built for interoperability. As applications become increasingly complex with many dependencies and components, both internal and external, it becomes challenging to navigate all of these dependencies. This is where API virtualisation comes into the picture. API virtualisation is the process of creating a virtual called copy of your dependencies and mirrors specifications of your intended API. By creating a virtualised back-end off your API design, as well as mocking your dependencies, you can –

  • Allow your frontend and backend teams to work in parallel
  • Create a mock API with dummy data, and distribute that to a few stakeholders both internal and external and get that early feedback and deliver API greatness

API virtualization and mocking is is fast catching on due to its many advantages. This article can help you better understand the concept and benefits of API virtualisation.

Building the API’s Business Logic

This is the phase where you take your machine and human-readable API design layer and convert that into actual code and business logic. Choosing the right technology framework is really important in this phase and luckily they open API design layer being language-agnostic can allow different developers in teams to do API business logic in different languages. Of course there are many different ways to choose the right programming languages, so here’s an article that can help. Tools like the Swagger Codegen project allow you to prototype APIs faster in the programming language of your choice by auto-generating boilerplate code from your API design. The code generator takes care of all the scaffolding in the API’s code, so your development seems to focus on what truly matters – the APIs business logic.

Testing the API

The testing phase is intended to reveal bugs, inconsistencies or any sort of deviation from what the expected behavior of the API was. depending on the mission criticality off your APIs you can perform different types of tests to ensure they function as intended. There are many different types of tests you can do like functional testing, reliability testing, load testing, and security testing, all of which can be prioritized based on your API’s objectives and target audience.

Creating API Documentation

Your API documentation is the face of your API. Think of it as a technical content deliverable that contains instructions about how to effectively use and integrate with your API. It’s a concise reference manual with all the information required to work with the API, supported by tutorials and examples.

Developers can auto-generate documentation from the OpenAPI definition layer through various API documentation tools. Documentation has a direct impact on adoption and growth of your APIs. The level of sophistication of your documentation can vary depending on the APIs use case. If it’s internal APIs, then maybe just reference documentation can suffice. External APIs tend to require higher levels of investment, with SDKs, tutorials, and a getting started guide.

Step 5: Define KPIs

Key Performance Indicator (KPI) is a measurable value that demonstrates how effectively your API is achieving its business objectives. While your API is being developed, it’s valuable to understand exactly what are some quantifiable measures of success for your API program. It’s easy to get lost in a sea of potential KPIs you can measure yourself against, so tying your measurable outcomes back to your API’s purpose and audience, defined in steps 1 and 2, can help. There’s two types of metrics you should measure yourself against.

Audience Journey Metrics

This is characterised by measuring the various steps it takes for your end user to reach and consume your API. Here’s a classic example of KPIs for a traditional API model.

Stage Consumer Action KPI
Interest for using API Registering for API key Time to register and obtain key
Desire for using API Understanding how to use the API Time to first 200 response from API
Desire for using API Integrating with API Number of API calls made over time
Advocating for the API Sharing APIs among social and professional circles Number of shares made over time

The importance of measuring yourself against quantifiable metrics could decrease when building a private API, which may not necessarily require the same amount of rigor. That said, In case of private APIs, qualitative feedback and anecdotes can serve as good yardsticks to measure yours API against too.

Business Goal Metrics

These metrics are tied more closely to your API’s purpose. If it’s a public or partner based API model, then pricing and growth are good indicators of your API success. If your API is for private, internal use, then the number of applications and processes integrating with the API is a good measure of success. Here’s a few examples of business-centric KPIs.

Business Goal of API KPI Example
Direct Monetisation Increase in MRR Twilio
Indirect Monetisation New customers referred through API eBay
Package Monetisation Customer lifetime value of customers using apps built through API SalesForce

Step 6: Collecting and Acting on Feedback

The metrics you define above can help you set benchmarks when collecting feedback on the quality and business value of your API. Once you’re done with the above phases, deliver the APIs on a basic portal to enable consumption by the right stakeholders, and get feedback. This step is all about getting some valuable feedback from an initial sample size of potential users. There are two parts to this step –

  1. Identifying early adopters who can provide you with feedback. You can leverage relationships with some of your existing customers, or scour for early adopters in channels where they usually hang out. This article from Lean Startup can be beneficial in understanding how to obtain early adopters
  2. Collecting and consolidating the feedback, and iterating on it.

This feedback needs to be processed and acted upon quickly, as part of the build-measure-learn philosophy. New feedback is again incorporated into the API design and development process, releasing new updates constantly.

Step 7: Marketing the API

Marketing your API is about educating your consumers on its benefits, and advocating for why it can be an integral part of the developer’s toolchain. At the end of the day, you want to make sure your APIs are being discovered and consumed, both internally and externally. In general, marketing is a combination of inbound content, including (includes inbound messaging and documentation) and outbound evangelism. This Nordic API ebook explains in detail the various stages to build a successful marketing program around your API, including various stages like establishing and maintaining developer relations, creating tutorials, and creating an advocacy program around your APIs.

10 Best Dictionary APIs That You Should Be Using Right Now

 

Advertisements

Thoughts on Companionship

Since this topic is a lot on my & my parents’ minds – I thought of exploring it better & structuring it for getting some key insights out!

As a kid, as far as I can remember – I have always enjoyed others’ company & guidance, infact it has been almost a shortcoming like every other kid where they look for approval of others in everything.
I have also enjoyed making special friends who I can confide in & can spend time with, share lunches, viewpoints, learn from, etc.

As I grew up – I started looking at it as a BIG cause for my well being & that is where I went wrong a bit. I started over depending for every small emotional & needs on others which resulted in unnecessary emotional baggage!

But there has been something that I have learnt about companionship – IT CHANGES with TIME. And I have always looked at future possible relationships with the thought that things can change anytime coz of no fault of either parties. So there is no point in stressing over something that is frivolous in its nature.
There is another fact I have learnt that with plenty of external responsibilities, expectations – it has become more & more a thing of convenience. Which people develop & then break off as per their convenience. Even I might have done the same to others UNKNOWINGLY coz I know I cant do it on purpose.

Most of the reasons I have distanced from others is because they have resulted in making me the kind of person I don’t wish to be (mostly clingy & emotional). And it has always felt right after distancing myself from most of them. Some of them I have tried to touch base again for some reason & they have been great or many have not depending on situations on both sides.

Hence I have decided to be extremely careful about where I would invest my emotional energies & how which I believe is a good sign. It is important that people are busy & passionate, achievers in their own rights in their own fields. There should only be some necessary attachment or need for support which should be provided when really required.

But mostly the Best Ideal Companionship lets you be the Best Version of Yourself that you can be! I don’t think its clingy, its downgrading, it maybe makes you think a bit at necessary times but I do think a healthy functional relationship is positive, encouraging & motivating, supporting for mutual benefit.

And my aim is that only in any of the relationship/ friendship I seek – I find it very suffocating when it becomes selfish & malicious, power play, abusive as these are not the traits that I have grown up with & permit to stand on value system.

And I have decided that I will not accept sub – standards come what may in terms of work, husband, girl & boy friends, hobbies, any ecosystem associated with me. #GodSpeed #WillNotRelent

Growing Up in India!

Growing up in Indian Middle Class society can be a bit middle aged like… and if one is growing up in an industrial colony then one can be more shielded in terms of what world has to offer!

In my experience too, I felt the world coming alive in its full potential & form only once I started working which is early to mid 20s! I believe that’s the difference between our kids & west where they are exposed to the full force from mid to late teens so we are about 7-8 years behind them in that exposure!

What happens is that we have a bit more refined way of approaching the new forms of life – living on your own, taking care of household needs, bills & utilities, safety + security, greeting up to strangers, transportation, planning savings + travel, etc. So our scope of error is lesser but we adapt faster as well.

Their social setting of Letting Things Go at individual & family level is what sets them apart! That doesn’t mean unleashing the devil absolutely but basically not bothering too much about every little thing is AWESOME!

For me to adapt to that at individual & family level to SLOWLY LET THINGS SHAPE UP has been the most ARDUOUS PROCESS!

Learning to build the blocks gradually & not giving up, shaping up oneself with time, enjoying small moments along the way, not giving up on ones values, Letting things be especially the ones which are not in one’s control HAS COME WITH A LOT OF EFFORT FROM INSIDE! It may seem so stupid & so so inconsequential but then one knows what one goes through.
For me applying myself, committing myself to a cause, adapting, pushing comes easy but Letting Go comes with A LOOOOTTTT of EFFORT! 🙂

One more important learning for me has been how to not lose your direction, your spirit for an obstruction – maybe one has to sacrifice on the speed/momentum a bit but don’t ever GIVE UP for anything! Become only stronger, resilient to everyone!

Another has been to give up on WHAT OTHERS THINK – That just doesn’t matter for the Hell!! One should be intuitive to what others are upto & are thinking but never give in to others intention.

Just believing in the Good & let your Karma do the talking has been my simple mantra for sometime!

PEACE

 

 

 

 

RIP Leila Seth!

Got news a bit late.. very saddened by the loss to Indian Law & Social Society.

Her book “Life On Balance” gave me a glimpse of her life & more than that gave me confidence to tread my path with all the confidence & conviction as per my beliefs.

A chance meeting during Bandra literary festival in 2015 shall be something I will always cherish – Thanks for all your contribution towards the society as a whole & for being an inspiration always. Will remember always in good & bad times. Leila-Seth

Let the Performance Come from the Gut!

I remember my Mom being an amazing Singer & Singing being her only indulgence apart from the daily household work!

I also remember her being very nervous before every performance & her Sir + co-performers giving her confidence before & during performance.
What I distinctly remember is that after every performance, the audience used to be stunned with her melody.

I used to wonder how – when she’s so nervous & I have hardly seen her practice at home, how do people go WOW with her voice.

Its much later that I realised, that performances need to come from the Gut to make an impact! Let it be an honest performance for it to be a great performance!

Also a quick mention for Pooja Sharma aka Draupadi for coming back from Hiatus.. Thank God & Thank You!

Past Guys Have explored

  • Engineering Studious Types
  • Engineering Just not sure of what he wants Types
  • Engineering Mumma Boy but chilled out Types
  • MBA – Marketing Go getter types
  • MBA – Softie types
  • MBA – Sales fadu & workaholic types
  • MBA – Fun & yaaron ka yaar types
  • Startup – Travel Explorer types
  • Corporate Professional Types
  • Second MBA Abroad still confused Types
  • Abroad Return yet Faltu Types
  • Sweet but Professional & Intellectually not there Types

Idea Types : ?? Smart + Professional + Values oriented

A sense of…

  • Humour
  • Good Food
  • Good Dressing
  • Travelling
  • People
  • Conversations
  • Values
  • Habits
  • Etiquettes
  • Health/Sports
  • Art
  • Design
  • Music
  • Books/Poetry
  • Maths (yes)
  • Science (Again yes)
  • Gadgets (Post 2000 effect)
  • Digital Imagery (Post 2010 effect)
  • Emotional Intelligence (Very Critical)

My Daily Routine

Wake Up : Between 7 and 8am.. The morning routine and checking news, sometimes do Yoga/meditation.

8am : 9am – Get Ready for Work by having a cup of tea, taking bath + getting ready.

Start work by 930am – Like a normal sane person, I like to go through the list of important deliverables for the day and the ones which are also critical from the near future standpoint. Then starts the work for assembling for the deliverables to be achieved – talking to zillion people, following up on million*million small tasks.
Keeping your superiors informed, taking their consent is the most frustrating task in the current headspace. Since we work in a stealth startup mode, not one person will take the call for any small execution as well.
Getting them on one page & ensuring closure of tasks proves to be like a huge mountain climb every time.
Add to that multiple perceptions floating around & managing amongst that conversations, reactions.

Around 1pm : 2pm – When I have my lunch with colleagues/friends, take a small walk around office and come back to our desks.

2:30pm : 7:30pm – Second round of follow-ups, chasing people, bouncing new ideas on white board to set your user journeys more optimised + functional internally & with vendors. Respecting everyone’s viewpoints while not negotiating on the main business objectives and ensuring a healthy work environment becomes all too overwhelming.

Post 8pm – When you arrive home, you still find yourself alive & breathing however feeling lighter post the day spent. But with no energy to workout … Yes its not good but not everything is as you desire.
Unwinding happens by talking to friends, tidying up the home, internet surfing, etc.
Around 9 pm – Talk to my family, eat dinner – check for movies, sitcoms to see.
Sleep by 11pm.

Some things to watch for :
– Do not over think, over stress, over worry – nahi ho raha nahi ho raha.
– Come out affable, comfortable, approachable.
– Despite all the efforts, if still one is keeping you at distance then let it be.
– Let Go of everything you can’t control.

India – a method to the chaos

This statement is quite casually put to explain the way India operates to people trying to understand Indian system. Even scientifically a lot of institutions have  tried to find justification to the above statement with no consolidated results to showcase so far. But it won’t be wrong to suggest that above statement DOES explain a lot what is wrong and still correct with Indian system. Someone can hear a song – “Phir Bhi Dil Hai Hindustani.. (Still heart is Indian despite everything).

The traffic is the first and perhaps biggest system management representation of how Indians operate, how they flung the rules, how considerate they are towards others. Not to say that everyone is bad or everything happening here is wrong as 1000+ people die everyday in India on road but as the optimist shall say 1crore+ people are saved as well :). The requirement is definitely for making traffic laws and law guardians ie traffic policemen/ladies more empowered – increase their salaries, make them more accountable, train them, help them in becoming no less efficient than an army officer or an investment banker for that matter.

Same can be said for law & order situation in India – the police administration, the judicial system are pillars without which any democracy or country will fail. In India, there are millions of ways of finding loopholes in here to find a way for yourself. A highly functioning country cannot afford to have 1 in 2 policemen who have oodles of pounds added around the tyre region who fail to empathise forget giving help to the needy. Again, a revamp with focus on their basic qualification, aptitude, attitude, fitness, salary structure is in the order.

Agriculture, Municipal societies, Education, Medical, Government services sectors are representing above examples’ chaos as well.

There have been a few sectors which have seen privatisation post the liberalisation policy of 1992 – Aviation, Telecom/Communication, IT services, Media, Food & Beverages, FMCG, Banking, Pharmaceuticals, Construction/Infrastructure are chief I can recall among others. These sectors have seen practices from abroad coming into implementation, a good level of competition to out do each other, high influx of educated youngsters joining them, consistent growth & contribution towards GDP, certain positioning at international scenario for India.
Not to stress that jobs in these sectors are in high demand at engineering, MBA and other colleges.

My country is great – nobody can deny or takeaway that from me. Am moment and again filled with the optimism for the highest notch that my country can reach. I am also one of those old school people who value the rich culture, family values, history values that my country keeps close to Her heart. Though what is required along with the Govt reforms is change of approach/attitude of my own countrymen/ladies – to not think of themselves first at every opportunity. In public places – think for the public too, while in a queue – keep your patience for others too, while driving or being driven – respect other people’s comforts/lives too.

Today, my country is highest growing nation in the world – its no mean feat achieved basis hard work of countrymen favoured by govt policies. Let us not stop till we are able to provide every single Indian anywhere in the world with clean food to eat, clean water to drink, healthy air to breathe, clothes to cover, shed to protect heads and few other basic amenities along with respect, dignity to withstand anything.

Love, Power & Amen!

incredible-india-4

Blog at WordPress.com.

Up ↑