I don't necessarily disagree with the points the author raises but to paraphrase JFK "ask not what your people can do for you, ask what you can do for your people".<p>I've been in team leading positions before and my approach is this:<p>1. Lead by example. You should be working at least as hard as anyone else who's reporting to you. Never make a fuss about it. Never complain about it. Just do it;<p>2. Shield your people from crap. Part of your job when you're in a leadership position is to shield them from crap. And by crap I mean things like management BS, customer requirements and so forth. Let them get on with getting the job done. Your job, at least in part, is to deal with these (typically overblown if not outright imagined) exigencies that customers tend to have. Likewise, your people should spend very little time in meetings, particularly with people outside your team;<p>3. Appreciate that every developer is different. We all like to work in different ways. Some of us are good at (and like) sailing through uncharted waters. Some like a far more structured environment. It's your job to cater to that to get the most of your people; and<p>4. Make sure each person knows how what they do fits into the big picture. This can be as simple as "you're writing this component so when the reporting falls over, which happens because of X, Y or Z, the system recovers". People work better, in my experience, when they have a level of understanding about where their piece of the puzzle goes and why it's important. Again, different people want/need different levels of detail here.<p>Too often management also thinks that team leadership just happens. In my experience, depending on the project and the size of the team, it can take as much as 25-50% of your time. Too often you're still expected to produce work as if you were spending 100% of your time programming however.
Sorry, but this is horrible, and simply not how leadership works.<p>It's the team lead's job to answer all of these questions on their own, by <i>interacting</i> and <i>communicating</i> with the team members. The role of the leader is to take up the communication slack of the team members because they are to <i>focus on getting the work done</i>.<p>Now, that's not to suggest that members shouldn't be communicating at all, but this is presented in such a way that if all team members followed it properly and consistently, they are basically self governing and don't require a leader at all.<p>The whole point of the leadership position is to account for each of these failures in human nature.<p>There was an old saying that was used in the Army that I remember fondly:<p>"If the student hasn't learned, then you have not taught."<p>In other words - it's always the teacher (or leader's) fault, because it is the job of the leader to <i>adapt to the personalities on the team</i> not the other way around.<p>It's easy to be a leader of all-stars, all you need to do is stay out of the way (topic for another day). Being a good team lead is about achieving all-star results with normal people.
My instantaneous gut reaction is discomfort. These are all good things, but the tone puts me off.<p>As someone who appreciates autonomy, I would rather be given an objective with advice on how to attain it than rules to follow. Even if the content is the same, it shows more respect.<p>In this case, the objective is simply situation awareness (<a href="http://en.wikipedia.org/wiki/Situation_awareness" rel="nofollow">http://en.wikipedia.org/wiki/Situation_awareness</a>) for both parties. The advice is to ask, debrief, and warn.<p>Dan Pink gave a good 10-minute talk about this sort of thing: <a href="http://www.youtube.com/watch?v=u6XAPnuFjJc" rel="nofollow">http://www.youtube.com/watch?v=u6XAPnuFjJc</a>
While there seems to be a lot of disagreement with the letter of these rules, there's an important and salvageable takeaway from the spirit of them. And that's clarity.<p>Always strive for clarity. Take the guesswork out of the equation for your direct reports. Set clear expectations for them and for yourself. Help them map out what success looks like, and what reasonable timelines to get there look like. Then let them perform. And be on hand to address questions and concerns as they arise. Be ready to support them when they need it.<p>From them, expect communication with each other and with you. There's a reasonably high probability that neither you, nor they, are mind readers. So don't operate as though you are. (And if you <i>do</i> have a telepath on your team, report them to the government for further study).
I've worked under you (at least, under someone who ran the team like this blog post suggests), and let me tell you, it sucked the life out of the entire team. The deadlines are the team lead's problem: if you aren't aware of where some project is at until someone tells you on the day of the deadline that it will be late, it's the lead who screwed up. How could you be so out of touch not to know these things on a daily basis?<p>Furthermore, if you tell these things to someone who does go out of their way to communicate clearly, they are just going to resent it as patronizing and start playing games with you. Not healthy for a team or any individual.
Wont work in a corporation. Essentially because of the stupid end of year reviews.<p>What will happen is that managers will count the number of WARNs you send out and number of bugs found after your DONE. Programmers will then game the system so that they never send out a WARN and increase the number of "UNCLEARs" to make the manager look like an idiot. They will also only send a "DONE" after they;ve put the system into production.<p>I think the bottom line is that the programmer needs to feel a part of the team and to trust the manager. Ie the focus of the team is in making a great product and that its understood that mistakes will happen once in a while. Also that its okay to make a mistake (once in a while) as long as you have a backout plan in place and/or your on call when your feature goes live.<p>This kind of thinking you will not find in a corporation unfortunately.
In my experience(mix of large and small companies) the one that seems to really confuse people is ASK. It seems the when people run into a problem that they are unable to solve, the majority do not think to ask for help or guidance, but choose the path of self preservation and do whatever they can to hide or spin the situation. This of course inevitably comes back to cause them or someone else in the pipeline problems, but that doesn't seem to stop most people. Is it just too powerful of an instinct for the majority of people to overcome or are we just becoming a "Cover Your Ass" type of society? Then again maybe I am just frustrated this week :)
These strike me as no-brainers. There's nothing really philosophical or controversial about them. I wouldn't even classify them as "teamwork", just basic communication.<p>If I hire someone to do a job then I absolutely expect them to a) ask for clarification if required, b) confirm with me once the job is done or c) warn me if the job will not be done on time.<p>I think most of the comments on here have read way too much into these 3 rules.<p>Tip: he's talking about how individual members of a team communicate with him: the boss. Nothing more, nothing less.
I see the author catching some crap, but I think it's undue. Well, potentially. The clearer you are with your manager, the smoother the machine runs. The only problem is that, in the hands of the wrong boss, trying to do the right things gets you fired. This really only works for the worker if the manager is equally honest and pro-active. And the only way to find out is to put your job on the line and gain that trust the hard way.
Tying these together, it seems the manager assumes all is well unless alerted otherwise. This, at an extreme, could be a "set and forget" style management: once tasks are given if you hear nothing you expect the job delivered on time. I think if this is communicated fairly it can be a useful approach, although its a wise manager who occasionally checks up on progress :)
I think these are really wrong rules: they are good for non-knowledge workers but horrendous for knowledge workers.<p>Here is what needs to be done instead:
Instead ASK, you should EXPLAIN task/project multiple times preferable using different methods of communication (email, in person, chat, etc.). You should also explain reasoning, risks, bigger context, and similar things. And ALWAYS ask for input and improvements.<p>Instead WARN, just check for status - often. Talk to people. We all know that software development has so many unknowns that the initial schedule is only valid if project is very simple and all unknowns are know. And many many times schedule depends on decision how things are implemented. Also WARN has negative connotation: for example, if an engineer comes back and says that she might get 10x performance improvement but things will be 10% late, is that WARN?<p>And DEBRIEF ... In my experience this is "outsourcing special": I learn that engineers in India like to say they are done when things are not done: just to be on time.
So, communicate? But it's surprising how many people do not do this. I think as a teal leader, you should take care to repeat these points to every new person joining the team.
Having managed multiple teams in the biotech/pharma realm, I can sympathize with the frustrated tone, but we are simply talking about communication.<p>Communication begins with the lead and is fostered in a non-hostile atmosphere.<p>You start with your group and then you speak to each team member individually. You discuss your communication and escalation pathways and then monitor your project.<p>As the lead and the driver of outcomes, you model outstanding communication and problem-solving (there are ALWAYS problems).<p>For me, I mastered the art of asking questions:
"What else can I do for you?"
"What other concerns do you have?"
"What are the obstacles in your path?"
"Do you have the resources/support you need?"
"Are you going to meet your deadline?"<p>There are no shortcuts here. You show your value when you proactively manage and bring projects home to successful conclusions. As the lead, it's your game to lose.
A friend pointed me to this discussion. I am really, really surprised at the number of comments which have interpreted this post as exhibiting a dictatorial mindset on the part of a team lead. The only takeaway as somebody has already pointed out is that _clarity_ matters, _communication_ matters, and communication has to be initiated by the person responsible for the job. In self organizing, agile (in the English sense, not the beaten to death software development model sense) teams, this is the norm.
Maybe I am just lazy, but I love it when I come across a problem I have to ask someone about, that usually means I can just kick it over to them and have them fix it for me.<p>Of course I spend half my time helping other teams, so they owe me dammit.<p>Forgot to mention, I also start warning people I am going to miss the deadline soon after I get the assignment. That makes it even more miraculous when I make the deadline. Don't worry, I thank all the little people who helped me while I take my victory lap.
4. Make sure when you explain "A" that the person you're talking to doesn't hear it as "B".<p>Not sure why, but this seems to be very common with programmers -- especially when one programmer is explaining a task to another programmer.
This reminds me of the Japanese business word "Ho-Ren-Sou", which stands for houkoku (report), renraku (contact, communicate), and soudan (consult, get feedback).<p>It also means "spinach", so it is easy to remember ;)