Pride and Joy

img src: https://www.pexels.com/photo/adult-apple-device-business-code-340152/

As a leader, the two most important things you can gift your team is pride and joy. Your team should enjoy their work and feel pride in what they worked on. These are the two fundamental premises that I base leadership on. If you are able to enable this for your team, you are a good leader.

Most other leadership traits and good working environments are derived from this base. Let us take a couple of examples, and see.

  • Great teams pour their heart out into building cool stuff. Have we all not realized that, we put in our best effort if we enjoy what we are doing?
  • Growth – Most folks grow in their career paths when they accomplish significant milestones. I measure milestones by impact. And people realize significant impact that they are making, when they feel proud. Pride swells when you accomplish more and more.

It is a cyclic process too. When you enjoy the work you do, you achieve more, feel pride, which makes you reinforce the joy in your work.

Company Culture and the Universal Workforce

I was reading this great HBR article on how praise and how it is delivered is very important. The article highlights the importance of this via an example of a manager from Germany working with a universal work force. As widely perceived, German culture is heavily result and detail oriented and quantitative. Praise, is often offered as an acknowledgement of the quantitative work delivered. The article described the manager as not being very comfortable with the american way of praise – such as saying “Good job” etc. And this lack of praise got folks to leave.

I do agree with this a 100%. And I would like to extend this to general cultural sensitivity. I work from India in a company spread across at least two geographies. And the folks on the US side are from even more diverse geographic backgrounds (such as the middle east). It is super important to understand the cultural context of the specific team you work with. In the current environment, there is no way, this can be generalized across the company.

Company culture cannot be decentralized either. Local managers (like me) are expected to handle the cultural implications of the local geography. While this is a noble idea, assuming that the local managers know best, it is necessary but not sufficient. This is because, given the increasing amounts of participation from remote geographies on larger projects, it is not just the local manager that the individual contributors work with. More often than not, on a day to day basis, engineers work with other engineers (or their engineering managers on the other side of the ocean). While the local managers tries his or her best to accommodate these cultural conundrums, if the relationship with the others are suffering, there could be bad side effects. This could work against the effort put in my the local manager, and hence making the local manager unhappy as well. Classic examples of cultural differences in the Indian context would be religious festivals (or pujas or functions) where the entire family congregates. In the American context, other than Christmas and Thanksgiving, there are probably no other similarities. Another example is the case of a close family member recuperating from surgery, where the employee would take some time off, or work from home. Again, in the American context, the love and affection is reflected in the quality of health care and care givers that the family member provides.

In closing, my firm belief is that, management in the 21st century is not just project management or technical management. If you are working in what we, in India, call an MNC (or a multi-national-company), management includes educating your peer managers in other geographies on your local cultural context. It also includes you learning from your peer managers about their cultural context and propagating to your team. The more the engineers in your team understand this, the more comfortable the work distribution and interactions become.

(reblogged from filterkaapi.in)

Ranting and Bitching

rant1

Rands has done it again. A very nice read for people managers in the tech world. I have experienced this first hand in my few years of management experience. It is defenitely true that, our first instinct as a manager is to see if you can act and fix the problem leading to the rant. But then most often than not, the rant is just a bunch of unorganized information that comes out of the employee, that he (or she) shares in the act of trust. The employee feels that talking about this to you makes him (or her) relieved. The most important thing is to determine when to act. The essay has a few nice pointers on that – such as “has this rant come in multiple times before?” Is the person ranting in pain? Is the impact leading to failure? Understanding and categorizing the rant is key.

[Read..]

(img src: flickr)

27 unwritten rules for conference calls

telephone

We recently saw the conference call in real life parody. While it was all hilarious and all that, in all seriousness, there are several rules that can make things better. TheMuse has a great list of 27 unwritten rules for conference calls.

Several gems here:

Schedule the call for the length of time you need, and remember that this can be five, 10, or 20 minutes. You should not be rounding to the nearest 30-minute increment.

Just like with meetings, start on time. Waiting for stragglers only encourages them.

If someone joins late, do not catch him or her up. It wastes everyone else’s time. Encourage this person to catch up with someone at the end of call to see what was missed.

Five minutes before the end of the call, warn everyone that it’s wrapping up, and ask if there are any questions. Do not let it run over if at all possible—it’s disrespectful of other people’s time.

Read the full article here. [link]

(image src: flickr)

Delegating vs MicroManaging

Just read a great post by Steven Sinovsky in his “Learning by Shipping” blog, which he started, just after he left MS. This is one of his few rare concise posts. He has a ton of experience and fantastic in-depth into software management, but some of his posts just run too long. I liked this one.

The problem is clearly stated in the words of a first year MBA student:

High-performing people generally want autonomy to get things done without anyone micromanaging them.  At the same time, as a midlevel manager, I’ve often had someone above me who’s holding me accountable for whatever my direct reports are working on.

I’m struggling to find the right balance between giving people their autonomy while also asking sufficient questions to get the detail I need in order to feel comfortable with how things are going. 

And Steve provides 5 tips to find the right balance between delegating vs micro-managing.

  1. Delegate the problem, don’t solve it.
  2. Share experiences, don’t instruct.
  3. Listen to progress, don’t review it.
  4. Provide feedback, don’t course correct.
  5. Communicate serendipitously, don’t impede progress.

I mostly agree with all of them. My favourites (which I try and practice as much as possible) are (2) and (5). I am a big believer in Management by Walking Around (for middle managers atleast). It is so much more productive for the manager and the team.

Maybe sometime later, I will write up something myself on what I feel one can do to find the middle ground. But for now, you can read the full article here.

Too Many Hops

Quite recently, I had been talking to a friend of mine, who was vying for a senior leadership position. After a couple of conversations with the recruiter, he was told he had taken too many hops, and hence the company was not considering him. I was thinking about this for a bit, and I thought I would share my thoughts.

I personally feel that, ‘rejecting’ based on this reason as the only reason seems pretty foolish and hasty. The least that one should do is to find out the reason for the hops, and how the hops happened.

Insecurity? Were the hops because of the candidate not feeling confident that he could do the job assigned to him? This might be a valid reason for rejecting, but then, we should also dig in into finding out how the fellow landed up that job in the first place. In the numerous interviews that I have taken, I have found that, one can easily figure this out, using some behavioural traits.

Performance. Were the hops because the candidate did not perform well? Did the interest levels dip soon after the candidate was hired? Again, think. Why was this not caught during the interview process? Again, performance measurement is subjective. It could be your perspective that he may have gotten the boot because of bad performance. But, this is a valid case of rejecting a candidate.

Burnt bridges. How did the candidate leave the previous companies? Were they amicable? Were they jumps with the management in full support? Were the jumps such that management tried ‘everything’ to retain him? Did he burn bridges? If the candidate had had personnel (not personal) issues because of which, he burnt bridges (fought with manager/team etc), then this is definitely something that should discourage you from hiring this person.

The fire brand. Is the candidate someone who has the fire burning in him to grow fast? Did he find that he has been increasing his net intellectual/management experience worth significantly by jumping from gig-to-gig once in a few years? If the candidate is someone like this, you can be sure that he would not have left the previous gigs in bad taste. He would have alternate plans, succession strategies, etc, that when he leaves, it does not leave a void. It is not necessarily a bad thing to hire this guy. Except, one should hire him recognizing that he is a fire brand, and craves growth. For a senior management position, this craving is a good thing. Stoked correctly, this fire brand can create miracles for a company.

To end, my opinion is that, too many recruiters make this mistake of judging a candidate by too-many-hops. Yes, I agree, there are some folks who have had too-many-hops because of ‘issues’, but you cannot generalize. In this current generation of companies, there are two kinds of people who race to the top – both the turtles and the hares. The turtles are the folks who have risen in the company (it took them 15 years in the same company to become the senior manager/director). The hares are the folks who gain experience and expertise in working through a variety of positions (these are the folks who have risen to a senior manager/director in 7-8 years). Think for a moment, and you can easily recall folks in both categories.