My Experience Leading A Team Of Developers

I’ve been working on my last company for as long as 8 years, most of it are leading a team of programmers. Here is what I’ve did in the past for self reminder.

Before we begin, my experience is somewhat unique, I’ve been a programmer for at least a couple of years before being a lead, prior to starting my career, I was also leading a small organization in the college, in which I tried a bunch of couple way of leadership style which leads to a lot of unsuccessful events and people leaving the org (This was a story in my teenage years and a story for another day too). After I started my first job, I was basically just a grunt programmer without any way of applying managerial skills.

I become a lead one day when a couple of senior people are leaving and there are no other person that could lead, looking back this was maybe a part good and bad decision, I’ve learnt a lot being a lead but that also took a lot of work and time of what I enjoyed best in the first place, which is programming. Some people are best being a senior contributor rather than being a lead, this was tested and still true to this day, so before you promote your team to become a lead, ask them if they want to do it in the first place.

One thing that is changed on my leadership style between my programmer and non-programmer day is I now lead with a programmer mindset, I’ll explain later below. Turns out this is also the approach that Satoru Iwata took (being a former programmer before being a Nintendo CEO, also did you know that he was a CEO at HAL labs too? And did you also know that HAL was named like that because they want it to be 1 step ahead of IBM? Symbolically through their alphabet naming).

So what Iwata did is basically viewing every interaction when he wears a CEO hat as an input/output similar to how a computer works. He goes into detail about it in the book “Ask Satoru”, but for the general gist is, every interaction between us and a computer, given a set of input, a computer cannot be wrong with his output. If we give one as an input and the computer processed it by adding 1 into it, the output is always 2.

That means if Iwata doesn’t get the output that he desired, he needs to make sure to give a different input, given he cannot do anything to the capabilities of “person” processing it. So whenever he get the output that he didn’t desired he tries to change his input until he get what he wants. This generally move the perspective of viewing the outcome and finding the fault from being a person/processing fault, to an input problem. If he had a heated discussion with another person, he don’t see the other person as stubborn on why the other person doesn’t accept his ideas, rather he see to it on how should he change his methods so that the other person would understand his ideas more. In short, if you brief your team with a task and it turns out not to be the outcome you expected, then the fault is on the person doing the brief, it’s on you.

You need to change your input to get a different output, and of course every person have different “processing” power that you could not instantly change, if you try to give a basic input to a senior person, you’ll get a good output, but try that to a junior person and you would get a not-so-good output, if you expect a junior person to have the same output, again, you’ll need to change your input, this looks pretty basic and evident but putting it into this kind of perspective really changed the way you look at every day-to-day interaction and stop putting the blame into a person whenever a problem occur.

Personally for me it is reassuring that I subconsciously did that too and not something that I uniquely came into it myself given a person as caliber as Iwata also come up with the same approach. There are also a couple of things that you could do to “increase” your team “processing” power, or rather to grow them, below are a couple of guidelines to do a 1–1 with your team.

One thing which needs to be considered is letting them know whether or not they are meeting your expectations. Do not put this off, do not avoid this discussion, you need to say this directly to the people you manage, always give them challenges, and set clear expectations. Below are a couple of non exhaustive list question to spark discussion. In general, ask probing questions, not a question that can be answered simply by a yes or no

• Is there anything you think we should remove from our development process?
• What decisions of the past do you feel get in our way?
• Where do you believe we are asking the wrong questions?
• What do you think I need to be more aware of or paying more attention to?
• Is there anything you’re doing that you’d like to bring attention to or for me to take more interest in?
• What concrete, specific feedback would you like to have about yourself?
• What has been the same for a long time that you think needs some more attention?
• What do you find most difficult, what do you find most frustrating?
• Where do you feel like you are being held back?
• Is there anything you feel is wasting your time?
• What do you consider your next big career step? What are you doing to get there?
• When was a time when you felt I personally let you down?
• When was a time when you felt I really helped you out?
• Name one thing you might do differently in my position
• What are you good at? (If you do a better job at managing your subordinate and keeping them close enough with their updates you don’t need to ask this in the first place)
• What are they struggling with?
• Are you invested in the project or would you prefer to work on something else?
• Are there people in the company that you don’t want to work with?
• Does they feel properly informed about what is going on with the project / company?
• Is this what you want when you come to work everyday?

As a sidenote since this post is derailed into the business of asking questions, you could also ask questions to other team to get a glimpse of what it feels like to work with them. Ask them If there’s only 1 thing that you could change in your team, what is it that you want to change. You’ll be surprised to know that their answer could potentially be a sneak peek of their team dynamics.

It can be daunting and confusing at first, since people will expect something from you given you now have the authority. At a simple step to navigate, create a simple 60-day plan what you want to achieve to the team when you started and share it with your team, ask them question, is there anything we should remove from our development process? Ask and let them decide because they are adults. Set clear expectations to them, define problems and constraints for your team, not solution. Work on each of them 1 by 1 on what are their strengths and how to work on their strengths.

I’ll introduce to the concept of leading credits, since objectively it’s hard to quantify every interaction with your peers or subordinates, this tool will help you navigate your daily interactions. So imagine if every time you do something that helps the team, growing them, teaching them, working through them to add their morale, every positive interaction that you do to the team will get you a leading credits. Now, if you ask the team to do your task, delegate things to them, and push them more than they can manage, you’ll be spending your leading credits. Spend too much and you’ll end with a negative credits, leading you to a team that is hard to work with. Things like this is pretty hard to keep tabs, but if you work with your team thoroughly, you’ll be feeling the balance for your own leading credits whether you’ll be asking them too much or you’re working more with them, in short spend wisely.

There may be a lot of more that I skipped or haven’t written during those 8 years journey, but this is enough for now, until then.

Originally published at http://ernesernesto.github.io on March 13, 2024.