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".
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.
There's a fine line from shielding people from crap, and shielding people from reality. In my experience, the latter happens way too much.
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.
As a developer, shielding me from crap means forwarding customer/client e-mails to me and telling me what they said on the phone, but never giving them my direct e-mail address or phone number.
In some organisations I feel that #2 is pretty much all the day-to-day work of the manager. Once the team is assembled, functional and given a goal (these might involve #3 and #4) then the rest of the project is letting them do what they're capable of by protecting them from everyone else.
I ask something similar of my people. I think it's fine, it's trying to set expectations about how you work together.
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.
I think of RAA when I think of project management.
R=Responsibility
A=Authority
A=Accountability
Make sure the team member understands what his Responsibility on the project is.
Make sure the team member has the Authority to carry out their Responsibility.
Make sure the teem member understands how they are going to be held Accountable.
Once underway, communication and feedback are the keys.
I'm all for shielding people from crap, but is that really what you think of customer requirements? Are you building the software for your own enjoyment?
Make the requirements intelligible for developers so that at the moment she needs it they're crystal clear. Rewrite this "can we move that button a tad on the left and make it blue like your tie" into "Move button X on screen Y 3px to the left and make it #5544df".
There is often a difference between what the customer says they want (which they label "requirements") and what they actually need. Sometimes they need to be told no, and when they ask for the third time and nothing's changed, that's definitely crap that your developers should be shielded from.
Just a further point, often the both you and the customer agree that there is a problem that needs addressing, but the customer is not sure how it should be solved. Alice from accounting wants the system to do X, while Bob from compliance needs it to do Y, which directly conflicts with X. Finally Carol in management has determined that they are not going to pay for a solution anyway.
This is exactly the 'crap' that you need to shield your developers from. Shielding developers is a lot deeper than just ignoring requirements.
Sorry, but this is horrible, and simply not how leadership works.
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.
Well what the article is advocating is "management by exception" - basically a callback system. Where as what you seem to be arguing is a polling system.
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.
And until a certain point, a programmer may not recognize when the code is out of hand. Even still, I sometimes spend an absurd amount of time working on something that seemed trivial, because it spent the whole day looking five minutes out of reach. Or a week looking an hour or two away. Those times don't generate callbacks because they don't seem like big enough problems.
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.
Sure the team leader can and should facilitate communication, but it shouldn't be too much to ask for someone to mark at ticket 100% complete when they are done. Leaders can block disruption so that focus can happen but it isn't their job to baby sit.
"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...
>>It's the team lead's job to answer all of these questions >>on their own, by interacting and communicating with the >>team members.
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.
My instantaneous gut reaction is discomfort. These are all good things, but the tone puts me off.
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.
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 a person that likes functional examples, "Exhibit situational awareness" is useless to me. "Great. How?" would be my first response. Ask, debrief, warn is a substantially better method for relaying this message to me.
Fun thing: it was actually pretty hard for me to put it into this tone, since it's not really mine. :) But I wanted it to be short and rememberable. I even wanted to do an acronym like they do it in the military. Just saying :)
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.
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).
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?
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.
> 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.
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.
Agreed, constant requests for status updates are annoying and unproductive. The lead shouldn't have to poll for data all the time but shouldn't expect everything to be pushed his way, either. I don't think it's that hard to have a good sense of where things are at from commit logs, building and running the software, bug reports, and casual conversation with team members. If, however, a team member is working on something high profile, risky, or is trying his best to crawl into a cave and avoid all human interaction, they are probably going to need special attention.
I worked under such conditions and liked it. The responsibility is on me to finish my task, report slippage, or clarify the requirement. No one pesters me for daily status. Knowing that trust was placed in me to do the right thing was wonderful.
Wont work in a corporation. Essentially because of the stupid end of year reviews.
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.
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 :)
Asking for help is an implicit admission of lack of skill or knowledge. People think this reflects negatively on them. In a good team it actually reflects positively, because it means the person thinks learning is more important than ass-covering, but then not everyone works in a good team.
You are exactly right, it is an admission of lack of knowledge. My thinking is that if the majority starts looking at learning and growing as a positive rather than a negative, then a lot more positive things will come of that. Now while this may take decades at large corporations, it is the kind of things startups and founders can implement in their small business and see some real change.
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.
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.
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.
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.
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.
* 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.
The entire attitude suggests a dysfunctional team environment. The author is creating a divide between him and those who report to him. All three points come across as complaining; complaining that it irritated him when someone on his team did not ask, debrief, or warn. My guess would be that the team lead is not an approachable person.
No where does he ask what he can do to help the team operate better.
Such an approach might work well when writing code for a well-understood feature set. While a lot of software has this characteristic, the problems I personally like to work on have a large number of unknowns. It is only the process of building a complex system do you fully spec it out.
Having managed multiple teams in the biotech/pharma realm, I can sympathize with the frustrated tone, but we are simply talking about communication.
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.
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.
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.
This reminds me of the Japanese business word "Ho-Ren-Sou", which stands for houkoku (report), renraku (contact, communicate), and soudan (consult, get feedback).
It also means "spinach", so it is easy to remember ;)
Not really. Each point puts me in a position where I appear as a weak or ineffective employee, which is likely to harm my coworkers and managers assumption of my skill level and therefore bonuses, raises and future employment.
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.
>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 think if anyone figures out a general solution to that one they'll probably have solved a much more important issue than corporate cultural dynamics; they'll have solved government.
The dynamics of risk change with the size of the entity involved. For example, in a small startup, losing a hard drive could mean the end of months of work - could kill the company. Or since everyone makes backups / uses hosted services these days ( right? ;) ), maybe a better analogy would be an employee being lost to sickness for months.
In a 100+ person company a broken hard drive should never be anything more than annoying, losing an employee is going to be unfortunate and might even significantly delay a product/feature; but it won't be the end of the business.
There's a raft of interpersonal dynamics which change too; the larger the company the less likely you are to be pally with everyone. Simple factor of surface area - you can't cover them all. So relationships become more formal. As spheres of responsibility begin to form, people develop moats around those responsibilities for better "separation of concerns".
At some point I suppose stuff starts to slip between those self-defined spheres, especially as people move in and out of roles, subtly redefining them each time.
Making sure you're not being negligent (or seen to be negligent) in a multi-million dollar company is kind of a big deal if you expect to work somewhere else in future (and especially if you intend to keep working at that company).
Again, this could be coming from my lack of experience in this world.
While your points are well taken, I'm not sure how those three points change between small & large companies. I'm going to focus on "WARN": the other two seem to be less contentious.
Working in small companies, if I'm not going to be able to make my deadline, the proverbial buck stops at me -- so I'd better own up to it, and tell my boss why it happened, and more importantly, what I'm doing to fix it.
Is it just that in a large company I can spread blame around a bit more? "It's not really my fault -- my team lead wasn't on the ball, we had too much pushback from sales, and if we could cut some of the dead weight from this team..."
Is that the issue? Or is it something I don't see?
It's less that you can spread the blame around than it is that the blame is spread around a bit more. Tasks get broken up, redundancy gets built in.
One of the most important goals for my "parent" company after we were acquired was to make sure that I (as the first and only employee) was not going to be killing the company if I left to pursue something else or got sick, etc.
So you've effectively got it, it's just that, in a big company, unless you're the CTO or in some other relatively lofty position, the buck probably does not stop with you.
Depends on the company obviously, YMMV, but I think the important takeaway is that "big" companies aren't just larger "small" companies - they're very different entities.
There's an interesting talk from Geoffrey West that (if I recall correctly) is somewhat related to this topic (the scaling of cities vs companies) - http://edge.org/conversation/geoffrey-west
Apologies if I've left you more puzzled than before!
I agree with you this does seem to be the case in most companies, but I think that is because a majority of the people would look at it the exact same way you are. If you, your manager, their manager...etc all think this way, then you will think a person asking you how to solve a problem is weak because you would never do it yourself. Now if the majority of the people at your company believed in these 3 points personally, then the whole dynamic would change. Granted this is a bit of a perfect world scenario, but it is one that any new founder or hiring manager can start putting into place from day 1.
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.
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.
As team leader, I appreciate honesty more than how someone sees their self. It takes a stronger person to be honest that they are in danger of missing a deadline. Resources and priorities can be shifted. Teams can adapt, and I'm sure that the product owner would like to know earlier rather than later that the deadline may be missed.
Because you don't just need to do it, someone on the other end needs to receive it. If every "ask" is met with annoyance, every debrief with "uh ok, still ready for september deadline?" and every warn with "but you promised! does this mean we will have to move the september deadline again?" then it's not hard to imagine people stop doing it.
His list implies a promise that he will not respond like this.
I think that is the intent too, but he really should spell out what his response will be to each of those things: "Ask", "Debrief", "Warn". The onus is on the manager to handle each mishap in a way helps the project and supports those doing the work.
In quite a lot of work environments, being a bearer of "bad news" will often lead to getting your head chewed off. A certain level of trust is absolutely required for workers to be truly frank with their project manager.
This was my thinking, too. We had a Lt in the air force that was fond of saying "if you have any concerns, come to me. my door is always open." The problem was that if you did that, your concerns were either blown off or interpreted as personal criticism.
The points made in the OP are good, but saying that is easy. It's when the deadlines start blowing by that the real test comes as to whether he can actually live up to it and not start backsliding.
Maybe they aren't put into practice because many leaders don't introduce the ideas to their team and set the expectation. You don't have to have a team of automatons to make good communication part of your culture. Set the ground rules and hold people accountable for the behavior. If you can't do this maybe management isn't where you need to be.
Not all leaders can commit to these rules themselves, that's why.
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.
Should be easy... the boss, asks his guys on the way back from lunch (as you really don't want to distrupt during work): "So you are doing that submission form, right? Is the shoe size field required? Great!" Wahaaa! :)
Easy to put into practice if your team is composed of automatons that will execute your directives with instant and willing obedience. But the reality is that we're just people, each of whom has their own concept of what's expected from them and what they're actually willing to do in return for a paycheck and it varies widely. In a perfect world we would all be striving towards a common goal with a clear understanding of what that goal is, the milestones to be reached and the methodology and processes to observe but none of that rarely survives the first sprint.
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.