4 Faces of a Team Leader

Recently being discharged from the Israeli Navy after serving there for six years, most of this time as a team leader, I thought to take this opportunity to look back at my time there, and reflect on what I learned, if anything, about the job.

Returning to army service after finishing my first degree, I didn’t know much about real-world software development, and even less about managing people. But the reality of army’s needs and limited resources is such that sometimes young and inexperienced guys get to step into large shoes. And so, after working merely 6 months as a developer, I got a proposition to lead a newly formed engineering task-force. After some deliberation, I took the position.

Leading this talented bunch of engineers and programmers has turned out to be the best experience of my army service. I learned not only how to manage version release or to how to support customers, but more importantly, how to work closely with passionate and opinionated people, that expect from you not only professionalism, but also empathy and understanding.

Knowledge Manager
As a team leader your first and foremost job is to manage knowledge. This is a process through which you convert ideas and requirements into a product: you write documents, prepare design specs, use source control to manage code, track schedule, etc. Going to meetings and preparing presentations, while less technical in their nature, are still basically knowledge management tasks. It takes some time to grasp the different resolutions in which knowledge has to be dealt with: you talk with developers about classes, with management about modules, with customers about features, with IT support about issues. These tasks require mostly analytical thinking and some basic communication skills, and university education does a pretty OK job at preparing you for this. But nothing prepares you for the job of managing people.

People Manager
The first mistake many fresh team leaders do, and I was no exception, is to think that you are supposed to be the undisputed expert on all the aspects of software development in your team – from C++ compilation errors to the difference between BSD and Windows sockets. It took me some time to realize that it’s not my job to be the fountain of wisdom. Surely you are expected to be fairly knowledgeable, and its nice to feel that you are the go-to person in some problem domains, but its essential to understand that your role is to be a facilitator, not an oracle.

As a facilitator (grand, but accurate word) you have several tasks:

1. To allocate tasks to the right people – to know which require the perfectionism of Bob, and which the troubleshooting abilities of Alice. But sometimes, challenging Bob with a piece of troubleshooting is also a good idea.
2. To share motivation – its not enough to say what has to be done, its also important to explain why it has to be done, for what purpose. The idea is that sharing motivations and getting the developers to see the bigger picture will transform them from contractors into owners.
3. To couch – that is to take the time to step back from the immediate problem and to share your philosophy and you view on methods and best practices

Seeing your job in this new light allows you to become less dogmatic about your own ideas and more prepared to accept criticism and admit mistakes. That is because you gain your self-esteem not from being always right, but from allowing others to realize their potential.

I am sorry to say that too often I cared more about getting the job done than about enabling growth, too often forgot to compliment people, and let them know how valuable they are.

Diplomat
Standing between the technical expertise of the developers and the political reality of the management, you are in a unique position to understand and empathize with both. And since often developers and managers have a hard time understanding each other, it falls upon you to mediate between them, explain each the others’ point of view and find a solution that would serve management needs (in terms of priorities, schedule, organizational constraints) without compromising developer’s engineering integrity (the need to plan for future expansion, to design for testability).

I remember one distinct occasion in each my manager and my senior developer got in a serious argument. I don’t remember the details, but I remember observing it with some amusement. While the manager stressed the need to solve the specific problem of a real customer, and do it as quickly as possible, the developer wanted to solve the general problem of the domain, and do it properly with a meticulous design. They both were right of course, but unable to see that the others’ point of view is legitimate as well. It took a considerable effort on my part to reconcile their differences, and reassure each other that his concerns are being addressed.

Psychotherapist
Army is a peculiar place to be doing software development. Programmers are expected not only to deliver features but also to do soldiering, like going on duty to guard base’s perimeter. And that often leads to confusion, anger and disillusionment on their part. Every now and than I have found myself having long, almost therapeutic conversations with one of the guys in the team, trying to put in perspective the latest news of some new hardships. Sometimes all you can do is empathize, and give time. It’s pointless to urge someone to work harder, when all he can think about is how “the system screwed him”.

Now, that this period in my life is virtually over, I feel that I learned much more from working with developers in my team than from anything else. And I am not ashamed to admit that when I see one of our guys excelling in his new job or venture, I can’t help but feel a little bit proud.