What You Think
'Yeah Pops' --- you say --- 'easier said then done. I've got a angry client or a lose tempered vice president to report to and he wants the application done before the road show. What do you propose I do?'
Surprise.
That is supposed to be a question you needed to answer the day you accepted your promotions and became a manager.
That's when your team expected you to know what to do in situations of this sort.
Having said that, the real question here isn't about what you do.
It is about what you 'think'.
Do you 'think' what your client or your vice president expects out of your team is justified or is he just being an asshole?
If he is just being an asshole for the sake of being one; your job is simple. What you hear in these meetings where the vice president or your client decided to throw a truck load to shit on your backyard; should *not* translate into action items or an unrealistic dead-line for your team.
How you do it is your seriously problem.
Look at him in the eye. Talk to him. Breathe. Convince him. Beg. Weave a story. Tell him what the word 'quality' means. Tell him why you are different from a million Indian programmers sitting in funny body shops running out of India. Kidnap his child.
I don't care.
Ok; the kidnap-his-child bit was a joke that wasn't even very funny --- but you get the idea.
If you 'think' he is being unrealistic and acting like a prick --- don't let the shit run downhill.
Just because you are stuck with a bad boss or a bad client doesn't mean that your team needs to open their IDE and start slamming their keyboards to write some code that will get the application to crash on the day of the big road show.
If you 'think' however that your boss or your client is acting like an asshole but what he expects out of your team is realistic and what he wants will genuinely help the product --- you and your team need to open that development environment.
Long story short, whether your team opens the IDE or not should *cannot* be decided by how big an asshole your manager is.
It has to depend on what you 'think' about the requirements at hand.
Remember; before you go up to your team --- think.
Do you think what he is telling you to do is going to help the product?
Have you decided that you are going to ask your team to open that development environment and write some code?
Wait.
Before you ask them to do that; you've got a few humbling exercises you need to indulge in.
Get Naked.
The --- "we're working weekends because we need to get this done by Monday" --- doesn't cut it.
No, it's not 'all they need to know'.
You need strip naked.
Tell them everything. The story so far; who wants it; why does he want it; who is being the asshole; why you think it will genuinely help the product; how will it save your job; why you want them to work weekends; why you want their help. Everything.
You cannot be keeping secrets and expecting people to give you cover-fire in battles.
Remember; this is a save-our-souls signal you're sending out and you're the one who is being rescued; so get the perspective correct when you go out to 'request' your team and ask them to work weekends or push seventeen hours a day.
The getting naked part is hard.
As someone who has requested his team to work in pressured situation more than once; for years; and have been lucky to have the best of builders on my team; I can personally tell you how hard it is to get naked the first time you do it.
What I cannot do however; is teach you how you can do this without feeling a little embarrassed.
If you're going to learn how to lead a team of genuine builders; you're going to have to learn this getting-naked part; by doing it yourself.
I can't tell you exactly how to do it; but If there is one thing I can tell you; it is that bossing around and being an asshole does not work.
If We Fail No-one Gets Killed
Say it.
Mean it.
Even when you know that if it doesn't work out; the sky will fall on your head and you will be left to die under a scrap load of shit.
When you're naked your builders can sense the importance and what the stakes are. The whole idea of If-You-Are-Not-Able-To-Do-It-Someone-Is-Going-To-Get-Hurt helps no one.
If you lack insight into your builder's brain I'm going to lead you into another little secret here which is going to be a life changing moment in your profession; particularly if you are managing a team of genuine builders.
Ready?
When your genuine builders walk up to you and start a conversation around how important the task is and ask you if they 'really' have to get it done by the end of that day; they are not looking for an escape route so that they can go home and sleep with their wives. They are just telling you that they are going to pull of a serious productivity stunt here; a magic trick that might fail and if it does; they want you by their side.
They aren't looking for an escape route when they ask you if they could ship on Monday instead of Friday.
All they are looking for is a safety net; and room to maneuver.
On a subtle; subconscious and psychological level they are testing if you are in it with him.
If they fail; and get stuck; are you going to give them cover fire or are you going to turn around and run like a rat.
I've had multiple cases of Can-We-Ship-Monday on a Friday evening. Some of them have been embarrassing. Walking up to a client and apologizing isn't easy. Having said that most of them times when it has happened - I've said "sure" - and meant it.
The result?
We've either shipped on Friday itself or we've shipped something better that the client absolutely loved on Monday.
We've technically failed more than one dead-line so far; sometimes by a day; sometimes by a couple; but here is the funny part --- the sky is still blue; it's still up there and no-one has got killed.
Learn How To Say Sorry Followed By Thank You And Mean It Too.
Somewhere along the line; after spending countless weekends and late nights in office; I ended up telling myself that I would try my best to see to it that my team members 'can' get out of office by six thirty. If they 'want to' stick around and work --- we're good --- but they shouldn't have to.
The reason to take this stand and to try to make it possible for them to get out by six-thirty is simple; every time I get an assignment done by requesting people to stay late, push harder or work weekends, it just means this:
- I fuc@#ked up at planning.
- I was incompetent at talking to the client or my managers and getting more time.
- I expected them to complement my lack on planning and incompetence with my team's added effort.
If you find yourself in this situation as a manager; remember; pushing the idea that the sky is falling and if the team does not push harder, work late-nights or work weekends, everyone will get screwed isn't going to help.
Let's face it dear manager; you fuc#@ked up and unless you work with a team of idiots chances are that they know that it was you who fu@#ked up.
You might as well come out and say it.
Try topping that with a sorry; followed by a thank you.
Then try meaning both the sorry and the thank you.
There are multiple ways of 'meaning' it.
For me; if you usually work a holiday; it is followed by a couple of complementary day offs when you do not have work.
I usually like to top that off with a team lunch or a party that's on me; not on the organization.
It doesn't compensate for my screwing up; but it's my way of saying three things:
- I fuc@#ked up.
- I am sorry.
- Thanks for the rescue and the cover fire when I was stuck.
You might have your very own style of saying sorry followed by thank you; but if you aren't saying it; and then 'meaning it' using concrete actions not just words --- you're just trying to pretend you're this big highly competent manager who is making an incompetent team 'push harder' when all you are doing is being an asshole and not even knowing it.
You're what we call, a whiner; a bullshit passer and a mail server.
How many times have your team performed a rescue operation for you?
How many times have you genuinely admitted your fu@#cking up followed by a genuine thank you; not just by words but through actions?
Do you have managers for whom you would happily indulge in rescue operations; or do you just do them because you have to; dear reader?
Discuss.
@BuildersAtWorkBookNotice
This ended up costing us all of our power to ever fight anything in the future, and it eventually destroyed the team, despite having a fantastic manager. I'm not sure what to do in this, but I think that most of we developers needed better coaching on how to say no.
I think it had a lot to do with the customer refusing to abide by the basic contract of the particular branch of Agile we were using: Developers agree to get this done in this timeframe, and the owner agrees not to add any features. This never happened.
But again, the bucking is kind of what hurt there, too.
Another problem is they could *always* justify their things that had to be added to the product **now**, to the point where most of the team took up a position of ennui.
A few thoughts on your comments.
> Despite having a fantastic manager.
If the team had to argue with the business or the client about what was realistic and what wasn't; was the manager really fantastic?
> I think that most of us developers needed better coaching on how to say no
Absolutely.
https://www.thousandtyone.com/blog/DoYouRespectTheIronTriangle.aspx
The last part of the article deals with the issue.
It's not just a developer issue though. Businesses or clients need to realize that what they ultimately end up doing by constant pressure and intimidation techniques is screwing their own projects --- which in turn translates to screwing up their business.
For the business; having no understanding, respect or consideration for realities and constraints of software development clearly does not help. Not having the willingness to listen is even worse.
Good managers are supposed to do the bullshit busting here.
https://www.thousandtyone.com/blog/OptimumUtilizationOfProductTeamsBullshitBustersAndSleepingPillsForMonkeys.aspx
Like I said in the post, whether the team takes up the assignment under pressure or not is not dependent on what an asshole the boss, the vice-president or the client is; but on if the person leading the team and the team 'thinks' it is a valid battle worth fighting.
Trying to fight every battle with just heroism does not always work.
https://www.thousandtyone.com/blog/SoftwareDevelopmentAndLearningTheArtOfGivingUpShamelessly.aspx
> Another problem is they could *always* justify their things that had to be added to the product **now**, to the point where most of the team took up a position of ennui
The manager and the team need to decide what they feel is a valid practical requirement that is safely achievable and what is not.
Then discuss possible workarounds and take a stand with conviction.
As you said; it is a problem of not being able to say ‘no' to constant and random artificial requirements. Not sure about your specific case, but my experience so far has been that the problem of not being able to say 'no' usually begins with a weak manager and moves over to the team.
Do keep the ideas coming.
These comments and ideas makes the process of writing this book much more exciting and are a good validation of the fact that what I am writing here is getting my point across.
Comments are closed.