A Lazy Brand of Leadership

When things go wrong on your team, when emotions come to a boil, how do you react? 

 Do you single out individuals? Do you start demanding answers? Or do you first take the time to understand how things went wrong before you single out or demand answers? Tread carefully, because this is what will define you as a leader.

If there is one trait that goes straight to the heart of what defines a strong leader, it is empathy. Empathy is the one trait that strikes an emotional cord between the leader and their teams. You don’t need to be socially connected to your team as a leader to practice empathy, because as it so happens, we are wired to be empathetic from the day we are born. As Simon Sinek points out in Leaders Eat Last, empathy is central to our survival as a species since the days when we were hunting and foraging as cave people. Without empathy binding our tribes, humanity as we know it would have never emerged.

A typical response to the need for empathising with your team members is to shy away, because most of us are uncomfortable dealing with emotions, especially in a professional setup. One possible reason is that we believe empathising requires developing a special bond with your fellow employee. This cannot be further from the truth. In most cases, empathising is really just as easy as these 8 steps -

1. Sense the emotional turmoil the fellow employee is undergoing. Are they angry, or just irritated? Do they feel disappointed, or let down? 
2. Record your observations about their emotional state by confirming. “I sense you are gravely disappointed”. 
3. Wait as this opens the door for a conversation. If the fellow employee backs off and denies this emotional state, you back off as well. If instead they agree or clarify their emotional state, you have a foot in the door.
4. Guess, based on what you might already know situationally, what might be behind this state of mind. Make sure this is an educated guess. “Is it because you expected a greater reward for the work you have put in?”
5. Converse so you either affirm your guess or lead toward the reasons behind this state of mind. If nothing else works, try - “Can we talk about what has led you to be so gravely disappointed?”
6. Relate to those reasons to help your fellow employee accept the turmoil they are going through. “I can see how this might have hurt you deeply”. Accepting emotions allows one to realise they are human. It allows them to stop fighting those emotions and move toward resolutions.
7. Understand how we got here. There is usually a chain of events leading to this particular reaction. Somewhere in that chain, lies the crux of the problem.
8. Resolve to work toward a solution that works for everyone. At times, the resolution is not obvious and requires further break-out discussions. "Give me some time to get other perspectives on this." On other occasions, there is no need to solve anything because empathising already led to the right frame of mind to help this person solve it themselves. 

When we watch 3-year-olds sense emotions and empathise with their irate parents, there is no reason why we as adult leaders cannot do the same with our stressed-out teams. When it’s really so straightforward, and really so natural for most of us, not practising empathy to understand before acting, is just lazy.

The Software Chef - II

Imagine you are a music composer. Would you reel in a singer for your soon-to-be-a-hit song without having heard how they sing?

Now imagine you are a restaurateur. Would you have someone be your chef without having them cook something for you first?

Yet, we work in an industry where we seldom bother to ask a software engineer to write us a small program before we hire them. Why is that? Is software development deemed to be not creative enough? Not skill-heavy perhaps? Then why do we deserve these pay scales?

Your resume here says you can cook....

Some believe programmers can be "trained". All that matters is how intelligent and willing you are. This probably applies to our mass employers (need not name them here). Programmers are a commodity here.

Others believe it is inappropriate to ask someone who says they have been programming for 5 years to write us a program. Almost taboo. After all, programmers will have other opportunities where they are not required to write a program before they are hired.

It all boils down to what you are really looking for. Are you looking to add to your headcount because you told your client there must be 10, not 9, programmers on this project? Or, are you looking for someone who can fit right in and quickly start adding value to your team? Are you looking for someone who clearly enjoys programming, and would bring that same passion to the work they do for you?

The culture of programming

There is a culture to programming, just like with anything else where there are many ways to do something and many heads working together. That culture defines whether I put a space after the '=' operator, whether I use a typical loop or instead apply recursion, and whether I define my classes strictly by properties or by function.

Wouldn't it be useful if we had some idea of the programming culture a certain programmer is bringing into our organization? Does it suit your own programming culture very well? Would they bring a much needed breath of fresh air to your programming team? Or would your senior programmers end up having to constantly review their code so it all "fits in"? What would you have to live with, and what would you be able to welcome with open arms?

You do not necessarily need to use a programming test to weed out your candidates. But, there is so much to be learned from such a test about a candidate's programming acumen and style, that it would be absurd to ignore it. Does my chef candidate prefer to make their dishes too spicy? I'd prefer to know that so I could tell them before I hire them - "We like you. Your Baingan Bharta rocks. If you could just turn the chilli pepper down a notch for our customers.."


Cook me something...

Depending on your inclination to invest time in this, and the kind of team you are trying to build, one of the following testing styles should ideally suit you. The tests could be "offline" - the candidates do this when they can, while trying to balance their other responsibilities and their current day job. Deadlines could be extended on request.

Be My Sous Chef For Today: The ideal test is one that involves having your candidate do something you do on any typical day. That would involve sharing the whole code base with them, or have them work out of your own workstation. In fact, many startups do prefer this "spend half a day with us and do what we do" routine.

A Three-Course meal please: You could come up with an interesting problem that can be easily described in words, and that does not have a ready solution on the internet, and have your candidate solve it completely. Add bonus questions to see which candidates will push beyond the minimum requirements. Ideally, the solution should also have certain clear "culture" requirements like "use Object Oriented Programming" so that the candidate knows they will be assessed for this as well.

Cupcakes: The third best option would be to have them implement a helper routine or class you have developed previously as part of your own work. You should provide compiled classes that they will need (hopefully just a handful) as libraries to use, and perhaps even prepare a skeleton of the class they are expected to implement, complete with method names, arguments and even docstrings. This should be something they can do in a few hours.


Finally, you may choose to give them one shot at it, or provide feedback from their first submission and let them decide whether they would be willing to have another go at it. You will soon discover who is willing to go the extra mile simply because they want their programs to be "perfect" and "bug-free". (There is a reason I used quotes here)


I have made it a point to use programming tests as part of my recruitment process. If you try this out someday, let me know whether it worked well for you. What would you change? How would you make things easier?

I Apply Therefore I Am

"An engineer is a professional practitioner of engineering, concerned with applying scientific knowledge, mathematics and ingenuity to develop solutions for technical problems." - Wikipedia.

Application. Problem Solving. That is precisely what engineering is about.

In the 4 years that I spent studying engineering however, there were few examinations that actually required solving problems ingenuously by applying knowledge acquired during the course of studying the subject. The only knowledge engineers in India need to possess is the fact that if you spend enough time practicing questions from the last 5 years' papers, you will emerge unscathed into the next semester.

So exams as a medium of testing application is thrown right out of the window. There used to be a saving grace however - the Final Year Project. Your one chance as a future engineer to completely embrace and understand a problem, design and implement it (if you are lucky, with valuable guidance from an able guide), and then proudly present to a jury what you have accomplished in one year.

Revelation

Over the past few months, conversations and interviews with young software engineers have woken me up to a reality apparently everyone else already knew about - no one does their Final Year Project on their own anymore. Well, almost no one.

Open a candidate's resume, find the Final Year Project title, and a quick Google search will reveal two things -

1. There is a paper published in an IEEE journal with the exact same title.
2. The project is available for sale at one of the local software training centers.

Teams of four are still formed to "execute" a project, but their members contribute more in terms of chipping in to the pool of money that will be used to purchase a neatly prepared, gift-wrapped project, complete with printed theses and presentations.

Bring the project up in an interview, and 2-3 basic questions later, it is already clear the candidate has no clue how to solve this problem. An excuse or two about amnesia later, the truth bundles out. This is followed by the familiar adage of "everyone does this".

How the examining jury does not realize this project was bought off the shelf like candy is beyond me. Perhaps they have also bought in to the "everyone does this" routine.

Certified To Be Trained

The monolith that is the Indian IT industry has long ago accepted the fact that engineering degrees count for little, and that every single fresh hire will need to be put through the paces of a training regimen. This has in turn lulled our future engineers into the belief that they do not need to apply or prove anything in their 4 years.

Why bother when you will undergo training in DotNet and Java anyway once you have been selected? Focusing on spoken English, aptitude tests and a decent score-sheet tend to pay off more handsomely in these interviews.

Solution At The Root Of The Problem

While not placing the blame squarely at the door of the Indian IT monolith at large, it is hard to see beyond it to find where the problem begins. Being a services based industry, it requires tens of thousands of employees each year - something that has obviously not gone unnoticed with ambitious parents who wish to bring up engineers, and the mushrooming new engineering colleges across the country. This has led to a side-industry of helping students push through the 4-year hurdle of getting a degree - first came the coaching classes, and then the "project training centers".

Instead of, or perhaps in addition to, running enormous training facilities for new hires, why do the behemoths of the industry not actively encourage final year students to take up projects with them? This has the triple impact of improving the quality of the engineer that passes out, while at the same time selling your organization to them and giving you prime access to the cream of the lot.

There are logistical issues to work out, but who is to say that students who can fund their purchases for off-the-shelf candy cannot instead spend on frequent visits to the closest office of a behemoth? Cash spent on grand recruitment schemes could instead be diverted to attracting more students directly from colleges to work on projects and prove their worth on the job, without having to pay them. This is not even close to being an original idea, but I am surprised it isn't more actively utilised.

No More Free Lunch

I like to repeat this. The day isn't very far when just like work migrated on the outsourcing silk route to India, it will migrate further to cheaper locations. When that happens, we either work on projects demanding a lot more application and problem-solving or build products for our local market, that again demand application and problem-solving experience. Both our behemoths and our engineers need to gear up for this eventuality. It has probably already snuck through the door and is hiding behind the couch.

The Software Chef

Imagine reading a 5-star Chef's resume. Now imagine this resume was written by a software engineer. The resume would typically have a section called "Skills" that would read something like this -

• Pots, especially flat-bottom ones
• Pans.
• Ladels. Expert in wooden ones.
• All kinds of ovens, including microwave.

If you now imagine yourself tasked with hiring a new 5-star chef for your restaurant, would this candidate be your prime target? No? What were you looking for in the resume? Did you expect the skills to read something like this instead?

• Expertise in sous vide.
• Learning and following traditional recipes.
• Baking
• Innovating with cooking techniques for fish
• Presentation of food
• Working under pressure on busy days

Then why do most resumes for software engineers read like nothing more than a laundry list of projects participated in and tools/languages utilized? Here's an example of a Skills section from a typical resume.

• OS: Windows XP/Vista/7, Ubuntu, CentOS
• Database: Oracle 8/9/10, MySQL
• Languages: Java, VC++
• Scripting: Shell script, Batch script, awk

Tell me about the journey, not the route
You worked on a project for the single largest bank in the world. But the team consisted of 50 people. Now how does one understand what your individual contribution was? You don't expect to be hired because you were on a team with 49 other people working on a huge bank project. Wouldn't you rather tell us what you learned along the way? What challenges did you overcome, either as an individual or as a team?

You worked 3 years on 15 DotNet projects for various customers. But how does one understand the challenges involved reading a description of the project in marketing lingo, probably pasted from the customer's website? What did you learn that you can apply in a similar project that requires using Python-Django-HTML instead of DotNet? How to design for scalability perhaps? How to interact with customers to improve usability maybe?

Think beyond the pots and pans
It would appear to be the single-minded focus on developing thousands of "workers", which is in the very nature of the software outsourcing industry, that is behind this fixation with brand names and technologies in a resume. Engineers are trained to become a Java Ninja or a MySQL Samurai, as opposed to becoming a Systems Engineer or a Database Architect. Eventually, with sufficient "rinse and repeat" cycles, engineers start associating themselves with the tools, not the problems they were intending to solve.

If you were really a 5-star chef, one would expect you to deliver nearly as good a result with the limited resources available in my humble kitchen at home as you do in your well-stocked restaurant. "Oh, but I can't do this without a microwave oven" will normally be treated with suspicion. Yet, I come across many a software engineer who say they are loathe to programming in Python after 5 years with Java.

"What happens to all those years I spent learning Java?" The simple answer is, if you spent 5 years learning how to use the sewing machine, then you might have missed out picking up the nuances in the art of tailoring.

Evolve, or dissolve
Are you prepared for a day where there may be no one using DotNet? Where the "Cloud" is the platform, and no one cares about an OS anymore? Where your software must run with similar experiences on a laptop or a tablet or a smartphone? Where all outsourced projects go to Vietnam or Phillipines, and we must build products for our own market instead? Where you are expected to be a problem-solver rather than a technician? After all, that is what an engineer was supposed to be, right?

What's The Objective?

Having read literally hundreds of resumes in the last few months, I have come to one definite conclusion. There is no value to the first thing candidates want you to read on their resume - The Career Objective. The Career Objective was intended to be a statement of your ambitions and expectations, yet it has turned into a chore for both the candidate and the recruiter. The candidate struggles to fiddle with adjectives, hyperbole and tenses in a desperate bid to make their statement stand out from the rest, while the recruiter is left with the task of demystifying a candidate from the Shakespearean prose that is facing them and to figure out how this one sentence differentiates this candidate from the rest.

I will be the first to admit that in my more youthful past, I have myself spent an hour or two sharpening the prosaic of the Objective of my career even before it had begun. It ended up being a melee of words like "challenge", "cutting-edge", "research" and "work-life balance". I will never know if that effort helped me land jobs or the interviews that preceded them. 

Most Career Objectives are a mash of the words "challenge", "skills", "growth", "organization" and of course "career". Toss them in a bowl with a random assortment of adjectives, whip up some hyperbole, and top it all with a dash of originality, and voila, you have an all new Career Objective. Here's a random sampling of a few that prove the futility of all the effort that goes into coming up with one -

• Peak of the bell-curve: "To pursue a challenging and growth oriented career where I can make meaningful contribution to the organization together with continuously enhancing my skills and knowledge."
• Slightly to the right: "To secure a challenging position where I can effectively contribute my skills as Software Professional, possessing competent Technical Skills."
• Slightly to the left: "To have a challenging and exciting career where I can explore my potential and become one of the best technicians and grow with the organization I work for."
• Remarkable: "To gain specialization in software development and establish myself at a remarkable position in information technology sector to efficiently contribute my skills forward the organization."
• Might as well add other obvious characteristics, like "I will wear clothes to work": "To pursue a career in software industry as an efficient dependable employee being resourceful to organization and affable towards my colleagues."
• Seeking a full-stop: "To pursue a challenging career in a fast growing software development organization that provides an environment for continuous learning, where hardwork, creativity and commitment are well rewarded and utilize the same for consistently rendering my service with enthusiasm in achieving the organization objectives and goals."
• Adjective attack: "To pursue an outstanding career and be a part of progressive organization that gives propensity to enhance my knowledge and skills which can be better extended for organizational as well as personal intensification."

  The most readable Objectives i have come across either look like this -
"Seeking Graphic/Web Designer position in an organization that provides innovative and challenging opportunities."
Or like this - "".

My intention here is not to poke fun at the Objectives people come up with. Heck, I came up with one such monstrosity myself in the past. Instead, I question the very objective of having to come up with one for yourself. Most of us use resumes from friends who just landed a nice, cushy job as a template for our own. This ensures our objectives in life have a hauntingly high correlation with those of our "successful" friends. Very often, the objectives themselves are written in flawless grammar compared to the more original remainder of the resume.

All recruiters soon come to the conclusion that most objectives have zero entropy. Why then do we still carry on with this pointless exercise of inventing a poetic vision of one's career and hoping someone will care about it? My sincere advice, for what it's worth, is to do away with inventing an Objective for your career. Let your work speak for itself. Your hyperbole and adjective are better reserved for any challenging work you have attempted and/or completed, and the skills you have developed doing them.