Leaving a mark...

I have been playing the role of a DW Architect for a large financial services organization over the past 6 months. When I reflect back on my duties and responsibilities, one aspect came out very strong that gets missed out in the job description.

"Leaves his Unique Selling Proposition trace in the project"

There are often a lot of other crap that the organizations look for like..Coordination between the business and IT....Owner of data models....Provides strategic direction to the IT team...etc...

Do you think Emperor Shah Jahan would have given a big job description to his architect,Ustad Ahmad Lahauri, when he set out to build the Taj Mahal? He described the Taj Mahal as

Should guilty seek asylum here,
Like one pardoned, he becomes free from sin.
Should a sinner make his way to this mansion,
All his past sins are to be washed away.
The sight of this mansion creates sorrowing sighs;
And the sun and the moon shed tears from their eyes.
In this world this edifice has been made;
To display thereby the creator's glory.

If you read the last line, it stresses the need to display the creator's glory. An architect should leave behind his glory after he is long gone from the project. That should be the true job description. It should be the one thing that the people would still talk about after he has resigned. The rest of the responsibilities are just enablers for the ultimate glory.

Celebrate even the journey and not just the result

I am a great fan of Aamir Khan, a fine actor in Indian cinema. But more than his acting prowess, what impressed me was his "own opinionated" view on movie making. His one little belief helped me realized a lot in my day-day activities. He has indicated that he believes in the process of film-making - the thrills, the sufferings, the enjoyment, the sacrifices, etc... more than the end result itself.

We do envision the end result, but a lot of us bury our minds in the end result so much that we don't enjoy the day-day process. For example, when we make software, we are so engrossed in meeting deadlines, living up to stakeholder expectations, daily status reports, that we forget to celebrate or appreciate the tiny successes like completing a unit of code without any bugs, writing a nice piece of documentation, being near your team member when he/she has a problem in her personal life, tuning a SQL query to less than 10 times its original running time. We lose all such fun events in the search of the end state, that even when we achieve the end state, it just doesn't taste that great. We pat our backs and are on-board the next "deadline train".

I am planning to introduce a "Success or Failure Celebration" event once a week in my projects going forward where people can celebrate their daily successes and failures. They get recognized for their daily successes. They can talk about their moments when they punched their fists. They can talk about the moments when their hands were there for their friends.

I will keep you posted on my results.

Ownership - Problems end with it.

Often, I find a lot of skilled and talented software engineers, who get stunted in their careers. Reason. Not skills. Not IQ. It's lack of ownership. They become more of "problem announcers" rather than "problem-killers". They just want to tell that there is a BIG, BIG problem ahead, but they don't want to solve it. Because solving is taking risk.

So, how do you get these kind of people to shape up? They are talented, because they find problems for you. Finding problems are like finding opportunities. So, what do you do ? Give them ownership. Give them the task of closing it out. Ask them not to just bring problems. But to "close" it with solutions. Once you give them the ownership, back off. Let them do their job. Don't micro-manage.

Nobody would like the auto-mechanic, if he just says there is a big engine failure in your car. But since the car mechanic has his business to run, he supports it with a big "Resolution" kit, which makes you feel to just leave the keys to him and then just pick the car when it is ready. He has ownership. He will complete it.

Productivity is just not about oneself

Last week, I have been trying to reduce my total # of work-hours to see if my productivity improves. It did, because I knew I had few hours to wrap up my work, so I wouldn't waste my time on long lunch hours discussing about Kanimozhi's arrest or taking multiple tea-breaks to vent my frustration on my boss.

But I am slowly realizing that productivity is just not about oneself. Its about the entire ecosystem. I had to elevate a piece of my code to User Acceptance Testing environment. And this was quite an urgent requirement and so wasn't a planned one. Now, even though I finished testing the code; the code couldn't get moved because of the frustrating bugs in a software development life cycle - "processes". So my productivity was based on the "process" productivity. There is "system" productivity, "team" productivity, "hardware" productivity and "off-shoring" productivity.

If your manager asks you to improve your productivity,ask him to:

1. Bring shortage or scarcity into the team
2. Show proof that its because of one person's productivity, the results are not achieved.

Is adopting scarcity a good strategy?

Yesterday, my apartment management stuck a poster which read

"Tomorrow, shutdown of water services between 8 AM and 12:30 PM due to repairs. Inconvenience regretted".

This water scarcity for 4 hours made me to wake up early and take my shower quickly. It forced me to use water conservatively for the next 4 hours till the supply was back. When I reflected back, I noticed that my day was productive, because of one little thing. The shortage. The scarcity.

So if I bring in scarcity into my everyday working style, will it improve my productivity? If I reduce my work time to 5 hours, will it improve the way I do my things? If I reduce my team size, will the output be better? If I reduce my commute time to work, will it help me to reduce my working time even further?

My strategy for the next few weeks would be to implement a "scarcity" based working model

I am my own management institution

I am not an MBA. Nor am I pursuing one. I wanted to get one. But unfortunately, we have too many constraints to get a good MBA degree in my country. The first one is CAT. I don't understand why should one be so sound in English vocabulary to be good at management. Why should I know what "Ennui" means when I can always use the word boredom? And even if I use the word "ennui" to a prospective customer in India, what are the chances that he will understand it? My sister would always argue saying that I sucked in English and these are excuses for not scoring good at CAT. I ignored. The second big constraint is time, if you are working. So I decided, that I will be my own management institution. I decided I will learn my own management lessons. And also experiment them.

This blog is all about my personal "practical" experience learning & experimenting management lessons. Strategy is going to be my first experiment. I will be sharing my experiences implementing "Strategy" and watching its "Results" in the following weeks to come.

Identity for quality

American Board of Internal Medicine (ABIM), a non-profit evaluation organization periodically tests the quality of 1 on 4 practicing physicians in the United States every year. The pass rates on the initial attempts have been close to 86%, which I feel is pretty scary, assuming that 14% of the physicians are in the risk of not allowed to practice till they pass.

Amidst a lot of critical reviews about the evaluation system, I feel it is still a very reassuring practice to let the taxpayers know that the system cares for the quality of the practicing internists. When was the last time, we, IT professionals took such a professional re-certification? We do have internal exams/certifications that our organizations mandate to pass to get our promotions/hikes, but none of them stop us from practicing the work that we are doing.

Is such a re-certification required for our profession, when most of the problems we encounter are answered by Google anyways? Should we need a authority which puts rigorous control on the quality of professionals coding/designing/managing? Should our identity for quality be a certificate and not a resume?

Deadlines or Resultlines

I have learnt to say "No" when my team members ask me "Senthil, Are there any timelines or deadlines?". A difficult one to utter, when you know you are placing too much trust on some body's commitment and interest. But I have had my share of luck so far. Success rate of 1 on 7.

Deadlines force you to think of dates rather than the outcome. Deadlines are music to the managers, but not to the solution itself. Is any woman given a deadline to deliver a baby? She needs to deliver a baby. That's it. It is outcome bound and not time bound. But does that mean that you will keep waiting forever till the solution is reached. Not necessarily, unless you have the funding to do so. I don't have that sort of liberty. I just stop the project. If I don't see outcomes or any kind of progress, I stop it. If I don't see the truck moving, (the pace doesn't matter), I abort it. It was an experimentation. With this approach, either I have quality deliverable or no deliverable at all. I call them "Resultlines".

Let me know whether it works for you or not.

Are you surrounded by irrational blockheads?

I admire Jason Fried, co-founder of 37 signals (37signals.com) a lot. His management theories are very simple to understand and hence easy to follow. They taste bitter for people who have been following astronomical, corporate lessons.

I have been lately working on a couple of consulting assignments, helping customers to strategize their BI landscape. I have taken up this principle not to give my customers too much of "visioning" masala and keep the strategy as simple and as worldly as possible. No bloat. Just give them what is required and what is implementable. My experiment gave me 50% success rate. But it gave me a 100% success rate in identifying a lot of irrational jackasses around me. How? Simple. They just couldn't understand simple things. When things were complicated and swollen, they loved it. When things were simple, they hated it. So what do you do with such blockheads? Ignore them? No. You can't. They are all around you.
Fire them? No. You can't. They are the heap in the organization.
Love them? No. You can't. You are smart and you will naturally hate them.
I decided to let them know they are imbecile, straight on their face. I decided to hurt their ego. I decided to make them feel that they are adding spam to the conversations. In this process, I was perceived to be arrogant. Who cares?

Is lateral learning an investment or an obligation?

I was interviewing one of my colleagues for an engineering position in my labs group. In fact, it started out as a request from my end to join this elite group. This group focuses on experimenting new features of a product and discovers business scenarios that would fit the bill for that particular feature. This group also fixates on identifying & abstracting reusable design patterns, which then can be serviced to various projects for specific implementations. Sounds interesting? I believed so, but my fellow colleagues didn't feel so.

The reason. "I have my project tasks to accomplish which fills in most of my day's time. I wont have time to contribute to this cause". I wondered why is it a cause. Then I realized the equation was about relating time spent to perceivable returns (appraisal comments). They felt learning a new feature outside the scope of a project was a very bad bargain. They felt it was an obligation that they were doing to the community and not to themselves.

When will the IT professionals realize that "lateral learning" (learning outside the scope of the project) is an investment to their own professional growth and not an obligation to their organization?