A year ago, the software team at DoctorCare was a team of one. Just me.
Since then, I have added two developers to the team, both junior. In previous positions, I’ve lead teams of up to 20 developers but in the past 5 years or so of working as a contractor and, in the past year, as a full time employee again, I haven’t had to play the team lead role. With this new growth of the team, I’m back to leading developers again.
Having been a while since I played this role, I thought it would be helpful to review how I lead and organize software teams, if only for my own benefit. Feel free to read along if you’re interested.
Hiring
This is the big one. Get this right and there’s a lot that can go wrong and you’ll still win. Get this wrong and it’s almost impossible to get things done.
At DoctorCare we follow the WHO method of hiring. For the most part, it’s been fantastic. We have occasionally missed but having a framework in place and sticking to it is incredibly important. Most people hire in the most random ways. There is no doubt that the average hiring manager thinks she is way better at hiring than average. It’s all self delusion. The science of hiring is mostly laughable and the state of affairs in business hiring is on the same level as medieval medicine. It’s terrible.
I won’t go through the WHO hiring process. Buy the book. Or don’t. But commit to a system. Make the system repeatable. Make it boring. Remove the variability. And you’ll probably be OK. But pick a system and stick to it. Few organizations do this right.
Estimations & Velocity
Answering the question “How long will X take to complete?” drives most software developers nuts. They hate the question because they don’t really value the answer. For them, being done isn’t really in the fun. The fun is in the solving of problems and the building of solutions. They also hate the question because it opens them up to all sorts of follow up questions like:
- Why is it going to take so long?
- Can’t it be done faster?
- Can we get someone else to do this faster?
- That’s unacceptable. We need it done by X.
Given all of the above, there’s little reason for a developer to ever enjoy hearing the question “When is X going to be done?”. But businesses live on the results of the software development process. So knowing when something is going to be done is important and answering that question is important. Here’s my take on it.
- Make sure you encourage a climate of honesty. Putting pressure on people to give you - the manager - the answer you want is a terrible waste of time. Even if not directly pressuring, having a culture or environment where software developers don’t feel comfortable in giving an honest answer is equally terrible. So the first step is to ensure that developers are free to answer the question honestly and fairly without intimidation or pressure.
- Don’t ever accept an estimation based on anything other than evidence and data. Intuition or gut feelings are useless.
- Check the due date on a regular basis. There’s no way that estimates are 100% accurate. Re-calibrating as the work is being done is important.
We use story points for estimations. Estimations in days/weeks/hours are just foolish to my mind. There’s just way too many variables you are trying to control when you provide estimates in time. Story points force a couple of things:
- They ignore the time domain when estimating
- They force you to track and report on your historical Velocity
Basically, story point estimations help to avoid lying to yourself. They force you to use historical data to calibrate your estimations and are the only method I’ve found to be repeatable, learnable and reasonably accurate. Here’s our velocity at DoctorCare broken down by quarter and person.
Generally, the story here is consistent. Sometimes there is a significant drop (50% decrease in my output starting in Q4 of 2018 for example). Mostly when I took some vacation time and consciously stopped working longer hours than I should have been. A consistent 300 points for me is a more accurate and sustainable velocity I think.
Having a backlog of data to base decisions on is much more likely to produce accurate outcomes than going with gut feelings.
Motivation
This topic is tricky and I prefer to think in terms of the opposites; how not to de-motivate the team.
- No estimations or no input from devs on estimations
- Lack of ability to pick your own tools
- Hard deadlines that do not consider the estimations
- Lack of opportunity to pick the topics to work on
A lot of motivational techniques I think are rubbish. What does not work:
- Withholding praise. Acknowledging good work from people is a default stance, not a motivational tactic
- Bribes and other bonuses don’t work (or, more likely, they cause the opposite results that you want)
- Asking people to work longer hours is reasonable for a while but backfires horribly if relied on too much
- Gamification or other trickery - unless brought forward by the team itself - I have yet to really see work well
What does work
- Being as fair about expectations
- Letting team members have a say in the tools and techniques they use
- Paying a fair salary from the start
- Listening to everyone and making sure their voices are heard and considered on matters relating to their work
- Coaching on a very regular basis