
When you're in a team that I lead, there are 3 things that I'd like to ask you - kkovacs
http://kkovacs.eu/teamwork-ground-rules
======
cletus
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.

~~~
ameasure
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?

~~~
cycojesus
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".

~~~
ameasure
That makes more sense to me.

------
run4yourlives
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.

~~~
luke_s
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.

~~~
sapphirecat
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.

------
szany
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.

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>

~~~
CoffeeDregs
Agreed.

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...

~~~
szany
As a Haskell user I have to say I love the "declarative leadership" idea...

~~~
CoffeeDregs
Cool. That's where I was coming from. ;) Painting with too broad and general a
brush:

Google, Haskell : Declarative

Burger King, PHP : Imperative

------
jonnathanson
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).

------
flatline
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.

~~~
queensnake
> 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.

~~~
flatline
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.

------
keeptrying
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.

------
rysulliv
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 :)

~~~
Joeri
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.

~~~
rysulliv
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.

------
RuadhanMc
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.

------
jeffool
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.

------
zipdog
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 :)

------
cHalgan
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.

------
sili
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.

~~~
kstenerud
It comes down to a question of culture.

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.

------
mrbgty
In other words, you, my minions, should obey my superior intelligence and work
in a way that doesn't annoy me.

~~~
alex_c
Are there any specific points in there that you feel are detrimental to
productive team work?

~~~
mrbgty
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.

------
Tom77
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.

------
talonx
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.

------
Hominem
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.

------
jerhewet
4\. Make sure when you explain "A" that the person you're talking to doesn't
hear it as "B".

Not sure why, but this seems to be very common with programmers -- especially
when one programmer is explaining a task to another programmer.

~~~
ojbyrne
Because software is, by its nature, ill-defined. If you fully specify every
detail of a project, you've essentially done all the work.

------
maky
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 ;)

------
StacyC
Very good points, and easy to put into practice.

~~~
tomjen3
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.

~~~
owenmarshall
>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?

~~~
duggan
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).

~~~
owenmarshall
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?

~~~
duggan
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!

------
blakerobinson
I don't necessarily think there is an issue with having these guidelines front
and center.

------
rokhayakebe
Short and sweet. Applies to teams beyond software development.

------
jsavimbi
I was under the impression that it was Assume, Lie and Procrastinate.

~~~
kkovacs
:)

------
drstrangevibes
What...is your name? What...is your quest? What...is the airspeed velocity of
an unladen swallow?

