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.
Interviews are a shot in the dark. You never know the state of the candidate on that one date, and deciding his fate based on how he solves a certain analytical problem, has never seemed the right thing to me.
What they have done earlier: I always ask about one project that the candidate has done in her previous work experience that she is most comfortable with. I ask the candidate, to then, go in depth, and explain to me. There are a few things that I can assess from this question:
Depth of knowledge: While knowledge of depth first trees and red-black trees are important, what I feel is more important, is how they have applied this knowledge. I go deep and probe into the problem, assessing, how deep the candidate has understood the problem, and the involvement with which it was solved.
Applied problem solving: How was the problem solved? You can test, how the candidate has applied existing algorithm techniques, or data structures to solve this problem. I ask “why so?” and “why not?” questions to see if the candidate took these decisions in an informed manner, or was she just implementing what she was told.
Big picture: I typically ask, where the particular piece that was developed new, or fixed, goes in the large product, or project. This gives me an idea as to how much the engineer is focused on the larger picture. The great candidates would know exactly ‘why’ they are fixing a problem, or developing a new feature.
Customer empathy: Yes. Every project has a customer. It might be external, or internal, but everything has an end-user. A developer in another team, consuming your API is a consumer too. I ask questions on how the candidate kept the consumer in mind. You get a lot from this question.
Communication skills: Was the candidate able to explain to me in a structured, lucid manner, about the problem, and how it was solved? I place very high importance in this facet. This is not to be confused with presentation skills. I do not expect engineers to be brilliant presenters (they are a few, I know of, though!). But, they should be able to communicate well enough to QA, PM, Design, and management. Else, there is huge productivity wasted here.
Attitude towards learning: Let us all agree, that, there is no one who knows everything. No one. So the best candidate, to me, is one, who realises this, and has an open slate to learn anything that is required, to do her job efficiently. There are a few ways by which I gauge this. I ask how much the candidate has learnt in the recent past. I ask about good projects and bad projects in recent past. I look for, if the candidate mentions her learnings on good and bad projects. I ask if something completely greenfield is thrown at the candidate, what would she do? Her structured methodology to crack it. I look for google, quora, online MOOCs etc.
Team player: While this seems cliche, I place a lot of important in this. I observe the candidate keenly on behavioural aspects. I ask questions such as, how the interactions with other teams such as QA, Design, PMs are? I seed sly questions such as – “These designers just don’t get technology, do they?” and observe. If there is one thing that I cannot tolerate, it is jerks. There is no place for brilliant jerks on my team. Sorry, cannot tolerate it. I will take a week more, with a slightly lesser brilliant engineer, but I would rather have fun doing it. Life is short. I want the engineer, and the team, to have pride in what they built, and jerks hamper this beautiful emotion.
Thinking process (PM interviews): I usually toss in a large green field project, such as “Growth for a Boutique Online Coffee Roasting Company”. I give the PM a few minutes alone. Once back, we work through the scenario together. I gauge structured thinking process here. I see how the PMs are making assumptions and communicating to me. I watch how the PMs react to suggestions from me. Is she accepting everything I am saying? Is she contradicting appropriately? If so, how is the dialog? Prodded deep enough, you check attitude here as well. I can sense condescension from a mile away.
I was thinking about all this today morning, and I thought, it would be good if penned these down here as well. I have been using these techniques for more than a decade for interviewing folks, and to a large extent, hit success. Sure, there were a few misses, but then, like I said, interviews are a shot in the dark. In the case of misses, you just need to realise it quickly and rectify.
This came up in a recent meeting with the Product team at work. We were talking about data and how in recent times, we have gotten a ton of it. We were also talking about how some of this data was actionable, and some was just there. In some areas, data was just becoming very hairy and unmanageable.
We spoke about Inferences vs Insights.
Inferences: You look at all your data. You crunch what you require. You ignore/delete what does not matter to you. You separate out key metrics and secondary metrics.
Insights: These are trends and patterns that you spot in your inferences. You then distill them, cross-reference them, and derive insights out of them. Because of a drop in metric x1, and a corresponding metric x2, the resulting derived metric had a double increase to x3. Add to it, seasonal variations, of a corresponding period in the last year, you get an insight as to whether what you have ‘built’ has been worth it or not.
Getting inferences is more or less a science, but distilling insights is almost an art. It takes experience, and an open perspective to effectively derive insights.
Insights also serve another purpose. They serve as basis for hypothesis, and experiments. You get insights using a subset of data, for a period of time, which leads you to make a hypothesis, which in turn you experiment for a different period of time (or a different subset of data), to prove it.
The above was the effective crux of the discussion that we had, and I thought this might be valuable as food-for-thought (if not anything else), for the few folks who read my blog.
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.
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.
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.
Fantastic interview with Richard Branson at TED – Monterey. The humility of the man blows me away.
My biggest takeaway quote from this:
Genuinely, if I bought something or had a particularly bad service in something that I did, I would go and do something myself to fix the problem. Like the time, I flew an airline, and I got really bad customer service, and Virgin Atlantic was born.