Who do you work for?

Who’s your customer?

Typically you work for your customer. A person who pays in return for your services. Its extremely important to know who or which one of them is your customer.

That’s easy, isn’t it.. OK. A small quiz:

Q. If you’re a software engineer.. Who’s your customer?

a) Project Manager

b) Team/Tech Lead

c) Your CXO

d) The actual customer of the company that you work for..

The answer almost always is one of the top three options.. and never the fourth one. By the way, fourth option needs to be the right one.

If you’re a manager, ask your folks this simple question and try it out.. Who do you work for? If you have atleast 50% of your folks say the name of the customer, you’re running a unique firm, most  probably a successful one too..

Minimizing the gap

The crux of the argument is that, its extremely essential that the execution team is well aware of the larger problem at hand. The actual problem that is being solved.

Most of our organizations have so many layers of hierarchy that the people who are executing have no contact whatsoever with the people who’re going to use their solution. No contact.. zip.. zero. Only time they probably meet the customer is some dinner some day.

This mode only guarantees mediocre solutions.. and yes, mediocre companies. The ones which depend on ignorance and mundaneness.. rather than enlightenment and innovation. Ones where developers are props (or famously known as ‘resources’) whose job is to stare at the monitor and tap the keyboard.

Developers are much more than that. Developers are problem solvers. They need to be treated that way.

In most cases that I’ve seen..

accessibility to clients/customer


the quality of the solution,

morale of the team and

overall comfort level of the customer.

As a developer, try to get close to the actual real problem at hand and contribute to the overall solution. As a head of organization, try to encourage your folks to engage at a higher level.

It benefits all the parties.. the developer, the organization and most importantly the customer.

Protect your dear ones

Many times you encounter code that reads as follows:

public class OuterClass{

private ContainedClass containedClass;

public ContainedClass getContained(){

return containedClass;



public class ContainedClass{

public void someMethod(){

// Do something



Typical usage:

// Usage of the class

OuterClass outerObj = new OuterClass();

ContainedClass containedObj = outerObj.getContained();


This is a very common pattern and you’d have surely witnessed it in some form or another. There is something essentially wrong with it. Before I begin, Let me tell you a real life instance first:

Imagine you have a girlfriend. Hmm.. for most of us this is easy. We’ve always only imagined a girlfriend 🙂

Back to the point. Lets say you have a girlfriend. A buddy of your calls one day and asks you for her details.

Your obvious response would be “What do you need to do with her?”

He says he has nothing wrong in mind, he just needs to check on something.

Your response “Tell me what you want checked.. I’ll check and let you know”.

This would be a very typical case of how you’d react on that kind of a request. What are you doing here? You’re trying to protect her from exposing it outside, fearing it may harm her or cause her some trouble. You abstract her out from your friend and act as her messenger at times.

Now lets look back at our piece of code above.

1. The OuterClass contains an instance of ContainedClass.

2. It exposes it completely through the method getContained()

But thats not the kind of thing you did in real life.. didn’t you. You abstracted out the details from the friend who called you up.

You need to follow a similar approach here. Lets have a look at this piece of code. (With the ContainedClass remaining same)

public class OuterClass{

private ContainedClass containedClass;

public void someMethod(){

return containedClass.someMethod();



Typical usage:

// Usage of the class

OuterClass outerObj = new OuterClass();


Here you have abstracted out ContainedClass from rest of the world. It can only be accessed through the OuterClass.

It is also referred to as ‘Law of Demeter”

It has many advantages:

1. It helps build more cohesive units and loosely coupled components.

2. The implementation details are hidden from outer world and can be easily modified if needed.

3. The dependencies on the calling objects are limited. It only depends on OuterClass now.

4. Testing is far easier, since you have less dependencies to satisfy.

Hope you found it useful. Do share if you have any thoughts on the above.

Object Builder alternative

Its a fairly common discussion and usually solved by

1. Constructors

MyObject(String name, String blog){
   this.name = name;
   this.blog = blog;


new MyObject("Satya", "onSoftwareAndStuff");

There is a small issue with it. During creation of the object, the parameters “Satya” and “onSoftwareAndStuff” do not say what they are.  One of the alternatives with dynamic languages is (with Groovy)

 new MyObject(name : "Satya", blog : "onSoftwareAndStuff");

This is much more readable as it says.. name is Satya and blog is onSoftwareAndStuff.

2. Setters

public void setName(String name){
     this.name = name;
public void setBlog(String blog){
     this.blog = blog;


MyObject obj = new MyObject();

This is more readable but spreads into multiple lines and repetition of variable “obj” and method ‘set*’ is uncomfortable.

3. Alternatives

To achieve the readability equivalent to the groovy construction, lets try the following alternative:

public MyObject name(String name){
     this.name = name;
     return this;
public MyObject blog(String blog){
     this.blog = blog;
     return this;


MyObject obj = new MyObject().name("Satya").blog("onSoftwareAndStuff");

Probably for a 2 parameter constructor this is an overkill.. but if there are more parameters, this looks a fairly feasible solution.

Any thoughts?


It’s been couple of months since I left Thoughtworks a.k.a TW, one of my dream companies (and still is..). A tribute has been due, so let me try that out here.

Joining TW  was at a time, when I was going through a very lean phase.. both personally and professionally. Leaving my startup wasn’t an easy decision, especially after spending about 2 years on a wonderful product LeadSimplified, which I would always reckon ‘My first Baby’. Professionally, pretty down for obvious reasons. I hadn’t worked in a recognized organization for last 2 years and in our part of the world the word ‘entrepreneur’ is not really a great tag to have. It only gets you into messy situations with your colleagues (especially your boss), if you know what I mean.

TW, I initially thought was the best place I could have gone at that point of time. The open culture, innovation and creative freedom that they practice would not let me feel out of place. I was right to most extent. There is a fair section of the organization which is extremely innovative and hungry (to do something worthwhile).

Getting to the point, A few quotes:

1. Our people are not talking about it (Rebecca Parsons, CTO, Thoughtworks)

A lesson in management for me. The emphasis on bottom-up management and employee empowerment is certainly applaudable.

Something that I touched upon in my article Decision making and organizations

2. Yeah. Of course. (Ketan Hajirnavis, GM, Chennai. Thoughtworks)

These were the exact terms used by Ketan when I went to him requesting for allowing me to register a startup. Any other company.. any other GM.. I would be out of the company. No questions asked. It was my honesty and confidence in TW that I told them about it. That’s the confidence that TW culture instills in its employees.

Couple of things that I would take with me always..

Of course, there were few things I didn’t appreciate.. but that’s for later.

Its an organization any good programmer/consultant would be proud of.. and I am.