If I inform you now about the risk of missing the deadline, I look weak, ineffective, etc (even if it is better for the team) but if I wait and some situation develop which I can say will prevent us from reaching the deadline, I don't look nearly as weak.
His 3 points are very good, but unless you are working a small company or a start-up, you have to play politics.
I guess that's the perspective I'm missing.
From where I sit, it's almost unimaginable that those three points are anything but a given. But I've never worked outside of small businesses/startups.
If I don't tell my boss -- the founder -- up front that we can't make a deadline, or that a feature won't happen, it's much more of a risk.
How can programmers help change large corporate culture so that playing politics isn't as important? Or, at least, so that more honest communication can take place without risking blowback?
I don't think it makes you look weak at all — putting the success of the team first shows leadership and maturity. Waiting for a situation that covers your ass but hurts the project is not likely to bode well for one's career.
His list implies a promise that he will not respond like this.
If they're not leading by example (as the writer says) then it's possible that "doing the right thing" and being communicative will eventually get you reprimanded, not rewarded.
Which is why it is important as someone who reports to others (most working folks do), it's important to make sure you know your management and choose (if possible) good management who you can trust and support your work-style.
I've been in team leading positions before and my approach is this:
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;
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;
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
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.
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.
So I prefer to shield people from having to deal with the crap directly, but I definitely inform them about said crap, and how what they do can help me keep the crap at arms length.
I ask, that when given a "requirement":
1. Question why we do this. Think: is this feature really valuable, or should I rather be working on stabilizing the server? If so, say so, let's discuss.
2. Question how to do it. Think: is there an easier way to implement this feature that gets 70% of the value for 30% of the work. Can we cut half of it? Then let's discuss.
And yes, totally agree with your nr.2. My people should understand what we are trying to do (ie. have context), but they don't need to know about all the crap.
It's the team lead's job to answer all of these questions on their own, by interacting and communicating with the team members. The role of the leader is to take up the communication slack of the team members because they are to focus on getting the work done.
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.
The whole point of the leadership position is to account for each of these failures in human nature.
There was an old saying that was used in the Army that I remember fondly:
"If the student hasn't learned, then you have not taught."
In other words - it's always the teacher (or leader's) fault, because it is the job of the leader to adapt to the personalities on the team not the other way around.
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.
It sounds like you want to regularly poll each of the developers, asking; "How's it going? Are you done yet? Any problems?". Where as the articles advocates a callback system, where the developer tells the manager that an event has occurred; "I'm done. I have a question"
In general a callback system is always going to make more effective use of resources than a polling system, both in software design and in management.
All this theory is fine. However the practicality is, some developers are never going to work in a 'callback' manner. You need to prompt and ask them and occasionally pull them out of whatever rabbit hole they have disappeared down. Others are going to absolutely chafe if you keep asking them for progress updates. The difference between an ok manager and a great one lies in being able to understand the human side of things and deal with each person as an individual, rather than just blindly following one theory or another.
Though if a manager polled me a couple of times that week, the second time I was the same distance into the same task, it would be a major trouble sign.
"If the student hasn't learned, then you have not taught."
I think the idea of the blog post is that the team lead will teach these 3 things to all the other developers... As a team lead, I think this list seems like a very effective tool to ensure that communication is not just one-way from lead -> developer, but is also developer -> lead.
No competent team leader is going to be caught by surprise by the schedule slipping on the whole project because of widespread problems, but it's easy to become derailed by a little "detail" which a developer didn't think was worth mentioning, but is actually a critical component which holds everything up.
The team lead can't ask about each and every tiny thing -- so I think this list is a great summary of the communication responsibilities that must fall to the rest of the team.
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.
Again, totally disagree. It would be wonderful if a team were self-governing, but it's rarely the reality. And if it is self-governing, you would need far more rules than just these!
However, I may be conflating the roles of coordinator and team lead a bit... in my role, I do both...
Are you serious? The team lead's expectation from his/her team is that the members are going to be self-organized. That is what the author of the article talks about - his _expectations_. How does communicating well interrupt getting work done in any way?
It may be the teacher's fault when your team members are novices, but not beyond a certain point.
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.
In this case, the objective is simply situation awareness (http://en.wikipedia.org/wiki/Situation_awareness) for both parties. The advice is to ask, debrief, and warn.
Dan Pink gave a good 10-minute talk about this sort of thing: http://www.youtube.com/watch?v=u6XAPnuFjJc
Exhibit situational awareness : declarative and flexible.
Ask, debrief, warn : imperative and brittle.
More importantly, the espoused framework only works for a development task oriented situation. What happens when the either bee behind to do some project or product management work and has a less task oriented role?
Quick edit: managers (e.g. below director level) are typically high-performing individual contributors who're given employees in order to amplify the manager's performance. The 'ask, debrief, warn' framework is essentially a manager's framework and views subordinates as if they were extra hands (grab that thing, provide tactile feedback to say it was grabbed, then (oh shit) warn me it was really hot). Seems an effective way for a manager to think/operate, but, as this thread shows, isn't appreciated by all subordinates since it points out that they're 'hands' rather than situationally aware rock stars...
As always, know your audience, I suppose :)
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.
That sounds nice, except that how is he going to know? He'll have to come by every day and ask "How's it going?". Which I've experienced, and is annoying. I prefer the asynchronous model.
No where does he ask what he can do to help the team operate better.
In many organizations I've been a part of:
* Asking is regarded as an admission of failure (and failure is regarded as a bad thing). Asking more questions (or even worse, clarification on an answer) can jeopardize your standing among your bosses, and, by virtue of the culture they cultivate, among your peers.
* Missing a deadline for any reason is a permanent mark against you, to be trotted out on every review and used as a reason to keep your salary low (I actually had a boss LOWER my salary, at which point I left in disgust)
* Reporting something done is an invitation for a dressing-down, where your boss humiliates you for everything not done to his satisfaction.
And so, with a culture of fear firmly in place, the standard operating procedure is:
1. Never ask questions. Do a shitty job if you can't do a good job and try to cover it up as best you can, or better yet, unload the project onto someone else.
2. Never report something "done" if you can avoid it. This gives you some "wiggle room" when the boss comes down on you over everything that's wrong with it.
3. Never say that you'll miss a deadline. Cut corners if you have to. Miracles sometimes happen. Maybe this time you'll win the lottery.
Now that I'm a founder, I'm working hard to undo that culture, keep fear out of the equation, and encourage communication and experimentation (along with the possibility of failure). It's amazing to watch someone go at it when they're uninhibited by fear.
Not sure why, but this seems to be very common with programmers -- especially when one programmer is explaining a task to another programmer.
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.
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 do have a telepath on your team, report them to the government for further study).
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.
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.
This kind of thinking you will not find in a corporation unfortunately.
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.
I think most of the comments on here have read way too much into these 3 rules.
Tip: he's talking about how individual members of a team communicate with him: the boss. Nothing more, nothing less.
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.
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?
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.
Communication begins with the lead and is fostered in a non-hostile atmosphere.
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.
As the lead and the driver of outcomes, you model outstanding communication and problem-solving (there are ALWAYS problems).
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?"
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.
Of course I spend half my time helping other teams, so they owe me dammit.
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.
It also means "spinach", so it is easy to remember ;)
