Through my career, I've "always" (with the exception of a one year stint in the middle) managed people. However it's been something I fell into more or less by chance, and I didn't have any formal training in management practices when I first did it.
I've recounted some of my learning experiences previously. But one of the most important lessons I've had is in how to rescue a team that's failing due to lack of communication and process. In this article I'll mostly focus on communication.
At one of my previous employers I got in over my head. I was managing the development, and managing the recruiting of the team. However I had no support - which isn't unusual in a startup, but also a real problem since much of the staff can be expected to be inexperienced in some of the roles they grow into.
I mean literally, no HR feedback or support in evaluating perforamce, no support or feedback from my direct manager on anything but technical issues which is the area I didn't need any help in.
Of course, at first I didn't realise I needed help, and now I can do without much of it.
The problems I faced were also a key reason I finally decided to take up my studies again, pursuing an MSc part time alongside my work.
There were three main problems:
Generally, large engineering teams - I'm talking about the size of a group directly reporting to the same person - doesn't work. There needs to be a hiearchy in place, even if that hierarchy is fairly informal.
If you're spending enough time on each member of your team, you'll be unlikely to be able to handle more than 5-6 people efficiently, depending on how senior they are. If you're lucky you have people that are strong enough that you can leave them mostly alone, and you can go above this, but you should never count on it.
I did, partly because I didn't know better, partly because I got no guidance from HR (and they were clueless about how engineering teams work), partly because I had great experience with the first few team members to come on: They did what was expected of them and beyond, and they left me enough time to mess around and keep doing some coding.
The problem comes once you get into situations where people have things to talk to you about, or when projects grow large and complex, and you get drawn between technical issues and man management. Man management is "soft stuff". It doesn't have an immediate effect on project deadlines, so it's put aside.
Except it does. It does affect deadlines, and it's even more important in crunch times than when things are easy.
Dealing with a team as large as that with no support wore me out. I nearly quit. I became depressed and stressed out, and started going home early, and became more and more unavailable to my team because I felt I didn't have time: There were always unanswered e-mails, or meetings to go to.
A while later I had a row with HR over my salary, and part of the reason was my lack of communication. I nearly quit over that, in particular because I got extremely provoked by the fact that they had the gall to complain of my lack of communication when a large part of the problem was that I felt I had nobody to talk to sort out the problems. In order words, I blamed my manager and HR.
While I was right in thinking they were as bad at communicating with me as I was with my staff, I started working hard at improving my part of it as the run in with them made me realise I had to do something. Not for their part, but for my team members part - they certainly did not deserve to be left to face the same burn-out and depression that I had been facing.
Through the reminder of my time at this company I didn't see any evidence of my manager or HR improving their communication with me much. But I did see a marked difference in how I was working, and learned a lot.
No, I don't mean ask for feedback. Some people will give you unsolicited feedback, and those people you generally don't have to worry about - they'll come to you if there are problems. Worry about the people who answer "it's going fine" when you ask them how things are going or how their project is coming along - when something DOES go wrong they'll still say the same thing.
They might not attack you personally behind your back, but they WILL (rightly) complain about how tough things are, and it will
This directly translates into a pattern of periods of relaxed work followed by frenzied crunch periods that just makes things worse
So, make people give you feedback. No torture instruments needed, but the time to sit down one on one with your team members is essential. It doesn't have to be formally, in a meeting room with you taking notes, but it does have to be semi-private. Enough so that someone will feel it's ok to tell you about why they've been grumpy at work, or why their project is going to hell and they need help.
But that's only the beginning. You need to show you're listening. You need to ask questions. You need to probe and show enough of an interest that they get that just fobbing you off with a "everything is fine" won't work. And the most important thing of all: When they do tell you about something that's going wrong, never blame anybody, including the person you're talking to.
Instead ask how they think it could be made better. Ask if things would work better if you assign someone else to help offload them so they can focus on the parts they do best. Be positive: They told you about the problem before it got serious (hopefully), so it can be fixed. That's good, not bad - problems always arise, but they usually only become real risks to the company when they're left unmanaged.
Never ever tell your staff you don't have time to talk. If you genuinely can't right now, suggest a time when you do have time and put it in your calendar the same day. Often if you have regularly schedules slots for your team members the need to do this rarely arises, as people already knows you're available for them to talk to, and will put off less important issues until you regular meeting.
But that does not mean emergencies can't arise.
A weekly status update at least in writing helps a lot. If someone runs into problems, you should see it on the way their status updates changes. But more importantly, a status update lets you get the basic technical stuff out of the way, and also gives you something to talk to people about - even the people who never talk to you or never talk to you about anything of substance.
Make your team understand you expect these updates. Just asking for them and not following them up doesn't help. Going on and on about them if your team sees no evidence that you ever read them also doesn't help.
During my most depressing period at the company I mentioned, I always went home at 5pm. Which was great. For me. I did that in part because I really, really had to get out of there. It was suffocating. I did it in part because I know from past experience that when you're on the verge of burning out you must take time out and try to get your energy back, or you end up working longer and longer days with less and less to show for it - your productivity just nosedives.
What I failed to realise was that it was happening to parts of my team as well. Part of the reasons for the crunches we were facing, apart from bad communication, was that the natural reaction to those crunches was for people to work until late at night.
A significant part of that work could have been done in a fraction of the time if I'd sent these people home, asked them to take a day of, and had them do the same work in a more controlled manner once they were well rested.
I knew that. I've been in that situation myself more than once. But I didn't recognise that in my team. I figured, hey, they want to work late, they can. I did ask them often "not to work too late", but coming from someone leaving them at 5pm when they're facing 5 (or 10!) more hours that's just demoralising.
Even if you can't contribute anything useful, you can provide your support (and cookies and soda, or whatever makes them happy...) And by being there, you can try to stop it from going too far: Even if the crunch is genuinely a problem, and they'll just be working late for a few days, it's counterproductive to have your staff keep working even when you SEE they're not getting anywhere.
Make them go home.
Once you've got communications working, you're still faced with chaos. It's just that you finally know just how chaotic things are.
I'm not going to say a great deal about process improvement this time around, as I think I can probably write a long article just on that subject, but I will make some general comments.
First of all, DO NOT try to force a huge process onto an engineering team that has never worked with one before. That goes even if individual members has, or even if the whole team has, but they haven't worked with exactly the process you want. It doesn't work. Been there, done that.
The result can be anything from grumbling "acceptance" coupled with subversion at every step, to outright rebellion.
My process improvement work started with me beginning the process of writing a development manual. Great idea, if it hadn't been so flawed: A development manual should enshrine what you're already doing, not set policy. I am grateful nobody laughed out loud when I provided them with the first draft. Instead it was silently but politely ignored.
Later, what I've observe work is a slow and steady process. Observe how the team works, and put in place one little measure at a time: A weekly status meeting, or even twice a week. Status updates. Change control forms. A simple change control process. Code reviews.
Expect it to take a couple of years to take a team from chaos to structure. But even after the first couple of weeks of actively trying to introduce simple changes you should start seeing improvements.
After I woke up to the fact that something had to change, I've had multiple opportunities to test out new things and improve my skills, and the result has been great.
One thing I was very happy about was that my first opportunity to improve was with the same team I'd had problems with in the first place - I quickly saw the change in the feedback I got both face to face and via other people, and productivity improved.
But what was the greatest part was when I was tasked with a major new project at a point when the team was split in two. I got a chance to test many ideas with a smaller group. While I still did not use regular one to one meetings, I did introduce more regular calls, and was much more available, and the difference was huge - for the first time in a long time I saw the team truly pulling together, and avoiding nasty surprises, and almost entirely doing away with the problem of regular crunches.
More recently, with my team at Yahoo!, I've had the chance to really make use of what I've learned, and spend a fair amount of my time specifically on strengthening communication and processes. It pays off. When the team works well together, my job is easier, and in the end we all benefit. That's perhaps the key lesson: Becoming a better manager isn't just good for your team, it also makes your day a whole lot more pleasurable.