Running a Software Development Shop
A collection of my views and experiences on running a software development team. Includes opinions that may differ from yours.
I want to start this post with a bit of background. Throughout my 10+ year career I have been a part of several teams, some better than others. I’ve already written about my views on what makes a good team on my blog. This time, I wanted to discuss some of those items and some additional ones from a perspective of a “team lead”. Basically, I want managers that will (hopefully) read this, come up to the team lead and say, “here’s X,Y and Z to support you, go make magic happen”.
Who is a team leader?
Let’s clear up the fog first. A team leader in this post, and in my view is not someone who is there to set deadlines, organize and assign work etc. but is someone who naturally has the ability to gather the troops and lead them into battle. In the end, it turns out that software development is constant battle. Some teams battle clients, some battle their management, some have internal battles — but in any case, it’s always a battle. As in the battlefield, some people are made to lead, and some are simply not. Most times, someone will be appointed to be team leader. This person must first earn the respect and trust of the peers (prove themselves in battle), only then can the leading start.
In some cases, a natural leader will surface and it is up to the management to recognize this and help that person help them achieve the goals.
While the battlefield representation stands, one must keep in mind that a leader does not necessarily mean giving orders. It means motivating the team to execute a strategy — which includes making important decisions when the time is critical. Also, the team leader must be the one person everyone in the team trusts, without exception. In my opinion, the project’s Lead Architect (if there is one, and there should be) should also evolve to be the “Team Leader”.
Expectations of team-members
As a team member, I expect my “leader” to be there any time I have a problem. This may seem like a lot to expect from someone, but it turns out there is a reason for this. You see, problems are bound to happen. Whether those problems are personal or professional doesn't really matter. I want to be able to talk to someone who (ideally) may not be my direct manager, and tell him/her. Furthermore, that person should then figure out what a proper resolution might be, and help me figure out a way to discuss this resolution with the management.
Two simple examples:
(1) A Family Emergency
This one seems fairly simple, and it is. Sometimes something happens that affects our productivity and presence. I don’t want to go through the usual channels and tell my boss I need a day off, etc. I want to tell someone I trust, and know they will convey the proper message to the people in the team that I am not bailing out on them.
(2) The Case of the Broken Computer
In IT equipment is constantly outdated. The moment we buy a computer, it’s already “old”. If I am having problems with my computer, or with a software tool, I want to tell someone who will not question my motivation and monetary implications but will instantly try and react — and help me fix the problem.
Your team expects you to be there when they need you, even if that means you are less productive!
A final point in the expectations is knowledge. The team leader has to be skilful in solving technical problems as well. Keep in mind, that does not mean the person must be able to code everything themselves. It just means that he/she is able to ask the right questions at the right time and offer proper suggestions when required. This is where my previous statement comes into play, that I feel the roles of the Architect and Team Lead are closely knit.
Expectations of the Team Leader
As a team leader, I expect my team to completely trust my judgement for all important decisions. This does not mean that everything I will say is correct, or right. Everybody makes mistakes, but you need to trust me that I will have discussed the solution with all of you enough that in the end, I will be able to make an informed, non-emotional decision that is reflective of your & the management’s best interests. As a team leader, I do not expect you to trust me the first day. And I promise to do my best to help you trust me. You are always encouraged to challenge me and discuss with me, but at the end, trust me.
That would be my expectation from the team, as a leader. However, I will argue that the major part of a team leader’s role is handling communication with management. He/she is there to basically “shield” the team from outside problems. That means there are things that this person will need to do this job better, more efficiently.
As a team leader, I want my management to also trust my decisions. They will be based on what our team needs the most, and while that may not always be exactly what you think it is, it will always be the best thing for that team’s (long-term) productivity.
Rewards & Perks
Living beings function well on positive stimuli. From my experience, when our team was simply acknowledge for the good work, we pushed even harder and stronger. When our work went ignored, it sometimes showed in the productivity/performance. Not because we wanted it to, but because that is, in my opinion, how we are all wired.
In my blog post referenced above, I already mentioned things like some time to work on personal things, additional challenges, etc. I have no problem with this being tied to performance.
In a perfect world, I would want my team to be able to dedicate at least a full day a month for learning.
The precondition for this is that the sprints are on-target, and the scope is met. While it looks like this will take away from the overall team productivity, I am willing to bet it will increase it. Ideas, technologies or designs that are developed as a result of these “personal times” are often incredible — Gmail was one such example.
While large companies can afford the luxury of having in-house restaurants with world-class chefs cooking food for the employees, even things like a fresh fruit basket delivered to the office will make most developers perfectly content. Buying things like breakfast cereals, yoghurt, coffee is the icing on the cake.
Again, in a perfect world, I’d want a team fund: 200-300 EUR a month, for the team, to buy perks. Fruit, food, coffee can all come out of this fund. But also things like motivational posters, Raspberry PI projects or tools that make our lives easier. I know it costs money. But in the end it comes to less than one month’s (gross) salary for a mid-level developer.
At the end of the day, I want my team to WANT to come to the office, because they can work in an environment they love, but also have fun.
Learning
Always encourage learning inside the team. This can come in two ways. One is internal — out of the above mentioned “20% time”, for example, by hosting what we called Technology Fridays team members can share their knowledge. The best example of this I have heard so far is a company in Ireland that hosts these types of lectures, pays for lunch for all the attending developers — but limits the time to 2 hours. Personally, I’d be perfectly fine with having this come out of the team budget mentioned above.
The other “learning” is personal growth. People change over time, so I would really encourage everyone to be given the chance to speak their mind about what they want to learn about, and what they want their careers to look like in the future. I would want to host yearly “review-type” events and ask questions like:
What can you, as a person do, to improve this team?
What can I, as your manager do, to improve this team?
There are more questions in the afore-mentioned blog post, but the general idea is that by evaluating ourselves, we are able to grow. If I (as a manager) know the personal goals of my team, I can help them achieve those goals. This circles back to my first point, that the team leader should be trusted for both professional and personal problems.
I am sure some of the points I have tried to make here are controversial (e.g. team budget) but I am also sure they can have a positive effect on the team. If you are the team leader, I encourage you to try and negotiate about them with your management. If you are the management and you are reading this because someone from your team sent you this link — tell them you appreciate that they care for the team, and try and find a way to implement some of the suggestions. Do let me know when you see the immediate benefits of it.
