When your developers don't speak to you
/What do you do when your developers don’t speak to you?
Not that unusual situation in the world of software development. Software developers in general have managed to earn a reputation for being difficult people to lead. A cursory glance at Amazon for software team management book will get you dozens of books dedicated to this subject (with the veiled theme of managing difficult people), including books with titles like “Herding Cats”! If there is a market for that many books then there must definitely be a need.
It’s obviously wrong to generalize and say software engineers are unsocial and don’t usually fit well with non techie rest of the world. That just isn’t true, spending all of my working life of more than 20 years being a developer, then hiring, managing and leading them I know that for sure. However, its also true that more often than not you’ll find it difficult to be friends with techies if you are not one yourself. Yet in an industry like software development, where communications and teamwork is essential to get products out properly, it’s important to have good relationship with team members. So how do you solve this problem? How do you make sure that your software team maintains good relationship with you (you = pretty much any role from an owner to a lead)?
Here are some tips from our experience that will lead to happy software teams and a team that trusts your leadership:
1. Shelter developers from “business stuff”
“With a software company, the first priority of management needs to be creating that abstraction for the programmers.
If a programmer somewhere is worrying about a broken chair, or waiting on hold with Dell to order a new computer, the abstraction has sprung a leak.”
OK “business stuff” is a horrible choice of words. What I mean by it is anything that a software company needs to run as a real business in this world. This includes things like sales, marketing, office management, making sure there that the air conditioning is running, even seemingly tech stuff like installing an antivirus or installing a hard drive. The idea is that development is a creative and high focus activity. Making developers do tasks that takes them away from this activity means you are making them lose their focus, it means you are making them do things that they are not good at. So although putting a developer on a sales call with a high profile customer might sound great because she can answer any tech question that can come up, you are actually wasting everyone’s time and making a dent on the developers ability to be effective probably for the whole day. Just as you’d shelter your accountant from debugging the latest issue in the code, shelter your coders from stuff that will only waste their time. You’ll be a star, you’ll make a huge impact on the quality of the code and find that the deliveries are happening on time. Joel call this sheltering the “the development abstraction layer”.
2. Trust your developers
Software development is really a craft. There is always an element of chance, an element of uncertainty in it. Which means there are times your team will be great, make you proud, produce the right piece of software at the right time and sometime they’ll make a total and utter mess. If you give them a feeling of trust - where you basically saying that you trust them to do their best, they in return will do their best. This is common in all team activity - sports for example. Trust empowers a team, makes them comfortable with you as their leader and makes the relationship with you simpler. DeMarco and Lister called it the “Open Kimono” (in their must read book: Peopleware) in a time when that phrase wouldn’t make you cringe. OK, cringe but follow their principle because this trust leads to better relationship and better teamwork.
Page 162, PeopleWare
3. Know that screen time is not equal to software
There is no relationship with the amount of time a developer spends in front of a computer screen with the quality and quantity of code she writes. She will write code that gets the a feature done sometimes in hours and sometimes in minutes - here’s the twist: for the same feature. Many things come into place that determines how much time is actually spent on writing a single piece of functionality. Sometimes it’s fast simply because a library was ready to go, sometimes it’s takes hours because a silly network issue made the IDE freeze, or sometimes it’s fast because a recent blog post by a favorite coder suggested a new algorithm. It’s impossible to predict. Yes definitely there is a tendency of some developers to be much better at coding than others, but that’s a hiring thing, the moment you chose to hire someone your are stuck with that person’s abilities and the inherent uncertainty of the software world. So if you see your coder “wasting” time in the lunch room when a super important bug is waiting to be fixed don’t go on hyper crazy mode - maybe she is just getting her brain to work things out in the background. Never use the quantity of time a developer spends in front of the screen (or even worse stays late for work) as a marker for performance for a developer. Getting out of that mindset will enable you to have a level headed conversation with your team and lead to a much better relationship with the team.
4. Break the ice
This is a big one if you are a non techie. There is an inherent “us and them” in the tech vs. non tech world. This leads to all sorts of weirdness and assumptions. A common misconception of a software team about their non tech manager (or worse old tech manager otherwise known as dinosaurs) is that they just would not understand how things are done. This often leads to a situation where the team is not communicating essential information (e.g. “there is no way in the world we can get that shipped by end of the month”) to you. This happens mainly because the team thinks you are just too different. The only way out for you here is to break the ice somehow. Go to a fun party with the team, make fun of yourself, admit you are indeed a dinosaur, whatever it takes to bring the wall down and make your team think they can talk with you.
5. Defend your team
“...the true price of leadership is the willingness to place the needs of others above your own. Great leaders truly care about those they are privileged to lead and understand that the true cost of the leadership privilege comes at the expense of self-interest.”
This is the ultimate one, if you just do one thing then do this. Let your team know that you have their back. You’ll defend them if things go wrong, if the boss screams he will be screaming at you and you’ll take the blame, if you lose the customer you’ll take the pain and not start venting your anger on the team. A good read along these lines is Simon Sinek’s Leader eat last.
The creation of software has so much uncertainty, so many moving parts and so many things that can go wrong that the team will always feel unsure of itself. Having a leader that understands this inherent risk of failure and acts as shield that lets them take that risk without worrying about the failure too much means a world of difference in the performance and morale of a team. And the team will forever be grateful for a leader like that.
OK, I’m off for today. Here’s the stolen Dilbert that does a good job on today’s topic! Good luck with your software team!
