The post is slightly long winded. You might want to grab a pop corn, sit back and relax as you read through this one. We are going to talk about about a horribly wrong management approach that a LOT of managers out there seem to be using even today despite of it's obvious disadvantages.

I could just tell you what the management approach is but I thought I'd take you all the way to India and introduce you to how Indian parenting worked when we were young, how we grew up and what civilized, educated parents in India are starting to learn about the human mind that the MBA graduates with their fancy courses in Resource Management just do not understand.

Ready? Let's start.

Unlike a few other countries out there, in India slapping your kids is perfectly acceptable and allowed under the law. This means that Indian parents are set loose and are free to slap their kids to discipline them every time their kids are found creating a ruckus. With upbringing of the kids mostly considered a social responsibility of the family where the government or law enforcement has very little involvement you would think that most Indian kids get slapped all the time.

The reality of it however, is very different. More and more civilized, educated parents of the Indian middle class family are starting to realize that even though you are "technically" allowed to, slapping you kid more even a couple of times in his enter lifetime is a stupid thing to do. All you do with beating is create rowdy goons and hoodlums.

This was not always the case however.

When we were young, casually slapping your kid to quite him down was considered pretty normal. Our neighbors for instance (who for the purposes of this post, we will refer to as 'The Fredsons') had no problem in slapping their kid once in a while when the kid was acting like a brat. Little Fredson played with us and as youngsters it was not an uncommon site for us to see Mr. Fredson come out and give his son a mild slap every time we hit someone's glass window with a ball and shattered it into pieces while playing. The game of Cricket would end instantly, Little Fredson would be slapped smack on his cheeks, though not very hard. He would cry for a few minutes, our parents would call us to our homes and that would be the end of the game (for that day).

Even in those times my parents took a slightly different approach of "talking" with me and my brother when we made stupid demands or acted rowdy. Instead of traditional slapping we received perfectly rational explanations on why we were not supposed to be doing whatever it is that we were doing. It would be a perfectly legitimate grown up discussion. Explanations were provided. Logic was used extensively. If we lost the argument, we obeyed, if we won, we had our way. It was that simple. Heck! It was a meritocracy where your ability to present your side of the story and use logic could actually let you get away with stuff that other kids our age did not even dream of getting away with.

Even back then, my parents understood a fundamental rule of parenting that most Indian parents did not understand. Slapping your kid has two aspects to it that stops your kid from doing the same thing again. The psychological aspect of it, which is to say, the kid feels really bad about having disappointed his parents. This aspect is really powerful. If you are a kid who loves his parent, their slapping you tells you beyond doubt that you have let them down. Then there is the physical aspect. Slapping can hurt, one, your body and two, your ego. It is this pain that is supposed to prevent a kid from doing the same thing again.

The problem with slapping your kid however, is that once you have done it a couple of time, the psychological impact of it wears out. Here is why this happens. You see, we (human beings) calibrate ourselves depending on the world around us. As human beings we are not very good at seeing ourselves as pathetic creatures who keep hurting others all the time. Our self esteems are much higher than we think they are. If you were the kid who was getting slapped, the first time you were slapped you would feel really bad psychologically. You just let your parents down.

The next time it happens, it feels just as bad. The third time it happens you begin tuning yourself. If it happens a little more frequently, your perspective starts changing and your mind tells you, "Bullshit! They seem to see a problem with everything I do. You know what? Maybe there is something wrong with them. Maybe they are just being too hard on me". There. The psychological aspect that was supposed to make you feel bad and stop you from doing the same thing again is gone. After all, there is something wrong with them. It's their fault. 

With the psychological aspect of it now gone, the physical aspect of it kicks in. This is the part where Aristotle often held an opinion that fear is synonymous to lack of habit. Scared of going on a battle? He asked. Fight a few battles, get used to the idea of being in a battle field, survive the battles, get habituated to the warfronts and your mind will stop getting all scared and worked up when you find yourself on the battle field. It is the best way to overcome your fear of public speaking if you ask me, but I digress. The point is, this is yet another example of the human brain tuning itself to the situation.

Once the psychological aspect of the beating has been thrown out of the picture, your getting habituated to the physical aspect of beating is just a matter of time and that just means your parents have to now increase the intensity of the beating to keep you from creating a ruckus again. Slaps have to get tighter. Grounding durations have to increase. And if your parents are to do that, chances are that you are going to tune yourself to the new intensity pretty soon. Your mind is going to get habituated to it. It's a vicious cycle capable of tarring relationships and creating goons or hoodlums out of perfectly smart kids.

With me so far? Good! Now let's get to the point.

Remember Little Fredson? Or the other kids who did get beaten up all the time. Let's replace them with your development team, the parents with the classical managers and the slapping with the classical "push" that the mangers apply on their team to make them work hard. You know, the classic, calling them in a meeting, putting them on spot or being "strict" with them to make them "work harder"? The push where you are constantly creating artifical deadlines, having three meetings a day and running around with Gantt Charts in your hand. Yeah! That push.

The problem with that push is that, just like beating up the kids to discipline them, there are the exactly two elements (the psychological aspect and the fear aspect) that are at play here. Your engineers (assuming that they are decent human beings and good programmers) want to do the right thing. Once you have applied the "push" on them a couple of times and used the carrot-or-stick to motivate them, you have tarred their psychological desire to do the right thing. Put simply, you have destroyed their intrinsic motivation and have replaced it with extrinsic motivation. You have turned perfectly smart human beings into animals who think with their lizard brain.

With this intrinsic motivation and the psychological element of doing the right thing, out of the picture, the only thing that is going to make them work hard next time is a "harder push". It's a vicious cycle capable of tarring relationships in a team and creating goons and hoodlums out perfectly smart, kickass ethical programmers which is EXACTLY similar to beating up your kids to discipline them.

With me so far? If you are a fresh pass out from one of those business schools you are knitting your eyebrows already. "It's easy for you to say Pops! You probably work in an organization where everyone around you tries to be reasonable with each other. We have to make our programmers ship. What do you suggest we do? Pamper them?", you ask.

Well, do exactly what my parents did while bringing us up. The approach was somewhat unconventional at that time but it worked. Actually, it did not just work, it did magic in our relationship and even today I feel just as comfortable in sharing most of my problems both in my personal and professional life with my parents. When they started these conversations, they moved from being parents to being peers. They became friends. And I didn't exactly drop out of school, become a goon or a thug. So I am going to assume that the approach they used worked and try to tweak it for you so that you can use it in your workplace. Ready? There are two simple steps involved here:

Step One: Listen

Ok, back to the basics. Step one is listening. Most managers (me included) don't know how to do this. That does not mean you stop trying. When someone approaches you with a problem, there is a devil in your mind saying, "I don't care about this microscopic shit he is talking about. All I care about is the ship date. It's just a effing database configuration! Surely they can figure out how to speed up the application, If I can just push them to...".

BAD MANAGER!!!

You developer is telling you something. Like I said, LISTEN.

Yeah, I know that devil is speaking in your head right now as you try to think of arguments and how this does not apply to your team and how your programmers are lazy scumbags who want to take you for a ride and you are thinking about those examples where Jack just took a leave three weeks before the ship day... and... and... and... he did not even pick up the phone when you called... you are thinking about your arguments. You are NOT listening to what I am telling you. You are NOT listening! And that means you probably do NOT listen to your developers when they come to you expecting help. See what I mean?

Stop Talking. Now! Start Listening.

Step Two: Talk With Empathy And Trust.

Empathy. Steve Yegge thinks that this the only thing you need to be a good manager. I think Steve Yegge is not just an awesome writer but he is also one hundred percent right. Your developers will bend over their back to rescue you out of a situation if you are open, candid, honest to them and are asking for help as a friend or a candid colleague.

"We are trying to expand the organization and get a bigger office by the end of this year, which is why we need new clients to sign up. Three of them have asked for a feature. I know you said it was going to take three months and I am going to try my level best to talk to them and see if we can make them wait for three months but if they do not budge and insist on getting it faster what do you think is a good estimate to give him? Also what are the features that you think we need to drop if we are to do it in a couple of months?"

See? That wasn't hard. The key here is, saying it with empathy. Add a little bit of genuine trust in your developer's judgment when he gives you a list of ALL those other features that you will have to drop. Don't argue with him telling how all those features are also important. Congratulations! You now have a programmer who is going to give you the best possible timeline without putting your project in danger, without going into hibernation, without writing F@#CK YOU Code and without shipping crap.

Do you really trust him? Are you just taking him for a ride? Is this a genuine urgency? Have you genuinely tried you level best to make sure that the urgency did not happen before you asked for help? Are you going to try your level best to see to it that this situation does not happen again?

Your developer is looking at you as you talk and these are the questions he is asking. He is going to be looking at everything you say very closely. Here is another advice: Don't try to fake empathy. Its like this: You'll get caught. How? Because you interviewed a hundred candidates and hired that smartest F@#cking candidate that you could find. You can't just expect him to isolate his intelligence to that time of the day when he is coding and leave it outside your office door when he enters your office. That's why, silly!

The Point

If you were lost in the digressions of the post and made no sense out of it what so ever, I feel your pain so I am going to make it simple for you and sum it all up. Striking similarities exist between good parenting and good management. If you want to learn good management, go watch a couple that has raised kids who respect them, love them, consider them to be friends and have not turned into goons, thugs or hoodlums. You will find ingredients of decently good management are all there.

Oh and every time you try to "push" your developers to work harder, might I remind you, that all you are doing is slapping your kid. I don't care how mild the slap is, you are adapting to a life style where your slaps are going to have to become tighter, your relationship with your team is eventually going to get tarred and you are going to turn perfectly responsible, ethical, smart working programmers into goons, thugs and lying scumbags who just do not give a damn. I'm just saying.

I wish I could give you a perfect recipe for teaching you how you can hire the best programmers out there or a perfect recipe for how you can stop being paranoid or how you can learn to trust human beings in general and your team in particular, but I can't. Teaching anyone how to trust someone else is hard. I suggest you start by unlearning everything about managing resources that you learnt in your stupid MBA course, throwing out your Gantt Charts, giving up the idea that you can control anything (leave aside the idea of controlling other human beings) and like I said, start practicing how to listen.

Yeah, that might get you started on the right track, but then it's a long way ahead and you are going to have to walk a few miles everyday. Oh and the journey does not have a exact well defined destination so if you are one of those managers hoping to find the end somewhere in the next three months and land with a team that has complete trust in you, super human output and unthinkable productivity, don't even bother to start. You are just going to wear yourself out.

On the other hand, if you see this as a life long journey and are willing to walk on this path of listening, caring about and trusting your team, for the rest of your life, you might go a long way, get a lot done and earn a few friends along the way. As always, all I can do is wish you good luck.

There is a restaurant in my neighborhood that has been around since 1922. They serve the most delicious Indian food you could possibly get. When I want to pick up some food to-go that is my default destination.

When I am with my office colleagues or people who I do not know really well however, I might choose a different place with a brighter ambiance.

The restaurant owners don't worry as much about opening an Italian restaurant in the same block where there is another Italian restaurant because they know that there are so many things that sets each restaurant apart from the other one.

The dishes you serve. The chefs you hire. The ambiance you create. Your menu. Your price. Your secret ingredients.

Even the kind of people who eat (or hang out) at your restaurant can be a deciding factor into who else eats there.

Every single factor complements every other one to decide who walks into your restaurant on a Sunday evening.

And invariably, each restaurant that stays around finds it's own niche and enough customers to keep going, within the couple of years of it's inception.

Software programmers, it seems, are different than restaurant owners.

We obsess about if our idea has already been built. And if we stumble upon someone who is doing something even remotely close to our idea we quit building stuff. We bitch and moan about all ideas having been taken. "Anything worth building has been already built", you say. "I had a great idea once, but there were already two huge companies out there doing exactly what I had thought of".

That's like saying that there is already an Italian restaurant round the corner and that means there is no room for my restaurant, even if I can serve the most delicious, thin crust crispy pizzas and build an ambiance where young college students will love spending evenings. So what if the other Italian restaurant does deep dish pizzas and caters to families.

When you think of building something, the only essential question you need to ask yourself is not if someone else is already working on the problem. The only essential question you need to ask yourself is, can you see the problem from a completely different perspective.

Can you add a little bit of you, to your solution?

The user interface, the feel, the number of clicks, the features (and even the non features), the people who hang out on your website, the niche, people who build your website, how your website feels. Just like the restaurant business, there are way too many factors that complement way too many other factors, which will decide who logs on to your site on a Friday evening. Can you tweak just one or two factors really hard to make your website stand out.

If you can, you should think of serving us your delicious crispy fresh software or service.

You don't need everyone. Just a few of us will keep your site (and your organization) going.

Go on. Start something, even if someone else is already doing it.

If you do it well, if you do it differently and if you keep doing it with consistency, we will come and we will keep coming.

I wish you good luck.

Building CRUD screens is a task.

Shaping a brand new idea into existence is a challenge.

Forwarding emails is a task. Mentoring a team that is capable of flocking and liking each other ... a challenge.

Checking the status of your project with your team is a task. Inspiring your team to move things and to avoid mitigated speech is a challenge.

Writing Module Specifications is a task. Making requirements interesting enough to get people to give a shit about them is a challenge.

Attending meetings is a task. Applying an innovative solution to fix the problem you were going to discuss in the meeting is a challenge.

Your organization, almost invariably, will give you tasks. That is what organizations do. Organizations do that because that is what they are really good at doing.

Your only (of course, I mean "only") hope for survival is taking on challenges not tasks.

If you are stuck with nothing bust tasks learning the art of morphing those tasks into challenges is a crucial ingredient for your survival.

The tasks you do will define your job role and your paycheck.

The challenges you undertake will define you.

How much of your day job is made up of tasks? How much of it is challenges? How much of it is tasks with hidden challenges vs. how much of it is tasks you can outsource to the cogs in the Indian body shops? There is a task on your task list right now. There is probably a hidden challenge in it right if you look under the hood.

The real question is, can you see it... are you man enough to pounce on it.... or are you just going to focus on getting the task completed so that you can move on the next task?

Just a little something to think about.

The moment you have an idea for an application, if you're like most people, you get really excited about what the product will be called. As you fancy a world where the product exists and people love it, you tell yourself, "Hmm, I wonder what a good name for the product will be".

Now, for those of us who have tried to name anything, from a baby to a website, we know that naming is hard.

"I wonder if this one is taken", you think of a name and before you know it you are spending your mental cycles in thinking a happening name and giving in one futile attempt after another only to find that all those names that you can think of are taken.

Then you get lucky and get a domain name, but then the twitter account for that name is taken.

"Those pathetic twitter squatters! I mean he is not using this account. I wonder if I can email him and ask him if he would be willing to sell the account to me.", you tell yourself.

See where you are going with this? Again, if (and I am just saying if) you are like most people, you are going to run thought loops in your brain, think of dozens of hot happening name for your product and wear yourself out before you even write a single line of code.

Naming a product you do not have is just about one of the stupidest things you can do. Ok, wait, actually there is one thing even more stupider than that. You know what that is? Naming a company that you do not have.

No, Seriously. How difficult is it to stick a logo with a sexy name on your template file once your product is built? How difficult is it to register a company after you have your first customer willing to pay you for your work?

If you spend days thinking about the name of the product, before you even write a single line of code you are a dreamer.

Wake up kid.

Write the damn product first. The pleasure of naming a product is supposed to be a reward for nearing the shipping of your product and you, are nowhere close to shipping your product yet. So snap out of it, open that IDE and start working. Let's see if you can build something which is even worthy of being named.

Oh and by the way, now that you have the IDE open, I wish you good luck.

When you hired Fred he was one of the few fairly productive employees you could lay your hands on.

There were a few minor glitches during the interview but then he seemed technically competent.

His demands were simple and very legitimate:

1. Some autonomy and ownership over his own work.
2. Good work with the latest technologies and frameworks out there.
3. A pay package that does not insult his capabilities.

A couple of years in the organization and you can see clearly that the cost of keeping Fred happy and satisfied is increasing steadily. Fred now just wants to work with the European clients because he has never visited Europe and is expecting a nice little business trip there. All of a sudden he cares little about the technology this European client is using or the autonomy that he has in his work. His primary focus is a big extravagant business trip to Europe.

You Cringe.

Fred in the last couple of years has morphed from someone who was highly innovative and driven by intrinsic motivation into someone who is high maintenance, low productivity and highly calculative about extrinsic factors. 

Once the barrier for being low maintenance is broken, it is a slippery slope down the hill. Fred suddenly feels that he is underpaid and overworked. Autonomy and quality of work mean nothing for him. Oh and by the way,  Fred also expects a promotion in this year's appraisal, even though he did not do a lot of 'real work' this year.

He is a borderline case of venting his frustrations on the employees and the organization.

Like it or not, when these symptoms show up, chances are, that you are going to lose Fred.

And then one fine morning Fred knocks on your cubical to talk about his resignation.

Your instant impulse? To offer him a raise. Match the offer that he is getting in his new organization.

After all he was once a productive member of your team.

My advice: Don't even think about it.

You lost Fred, the day his productivity curve started going down. In fact, you lost Fred, the day he stopped working for intrinsic motivation and starting whining like a baby for that European trip.

You can either take my word for it or you can try and match Fred's salary. If you went the later route, chances are that within six months to a year, you are going to see Fred knocking at your cubical, wanting to talk about his resignation again, this time with a higher offer letter.

Instead of trying to get Fred to stay, you are much better off letting him move on and letting someone else in his team take up his responsibilities, even if Fred is your alpha geek.

As scary as it seems sometimes new faces and thoughts are good for your organization. Stop your negations with Fred, let someone else in the team take up his responsibility and  let life get back to normal. Or you can go hire but if you choose to do that, do it like your professional life depends on it.

Either way, I wish you good luck.

Oh and if you are sitting there negotiating with Fred you are just wasting your time and energy.

You have gathered for a meeting. This one is not the casual sitting around the fire, chatting about the meaning of life and discussing the movie at the theatre in the next block, meeting.

This is serious business. You know it. Your boss knows it. His boss knows it too. They are all there. Pumped up. There to take a decision about the features that we will need to build in the next one month to wipe out the competition or maybe to pick a framework for your next project.

"So, do you think we can ship by end of this month?"

"Which framework do you think we should build this using?"

"How many more people do we need to get this done by the end of the month?"

Yeah. I know. Its tempting.

"Gee Boss, I think we should build this using Dot Net Nuke and hire about three interns and a senior engineer on the team."

Bad move.

Shut up!

When you are in a meeting your job, as a manager, leader or whatever it is that you call yourself or see yourself as, is to avoid decisions from being taken over a single meeting. Classical business analysts and managers will tell you that this is because you need to protect the team from your upper management. That explanation is almost always bullshit. Your team does not need protection from the upper management.

If your upper management is getting you on a meeting and asking you these questions chances are that you are one lucky son of a gun who has landed with a really strong senior management team who cares enough to ask you what you need.

That doesn't mean that you have to give them an answer right away though. Like I said, Shut up. You need some think time on the time your team is going to take working on this. You need to see if Dot Net Nuke really fits what you are trying to build, or will you just end up building yet another Frankenstein.

Overall organizational decisions taken in a single meeting are equally risky. So Fred miss utilized the corporate credit card. You are in a meeting discussing the problem. Someone three levels above you hastily panics. "So, do you think we need to stop the corporate credit cards for everyone? Are they really needed?" - Again, temptation to give your instant opinions. This is one isolated incident. Maybe it needs an overall organization policy change. Maybe it does not.

Whatever it is, the only thing that I can tell you is that you do not need to decide the solution over that meeting.

Breathe. What you need to do in this situation is protect yourself and your management from one of the biggest threats of the software development world: Panic.

When you are in a meeting, the pressure to take the right decision is  immense. Chances are that you are not going to be able to Blink well in this scenario. The solution, the right solution to the problem is most likely to show up tomorrow morning, in the shower.

When you answer in a meeting, your management listens to you and decides to move in a particular direction, all of it happening during that one meeting, you block the possibility of the best solution showing, in the shower the next day.

As tempted as you might be to open your mouth during that meeting, shut up. Sleep over the problem. Give it some soak time. Chances are that the solution you have the next morning will be much better than the solution you have during the meeting .

When it doubt, choose silence over spontaneous reactions in meetings. You are not going to make the best of the decisions in a meeting when you are surrounded by people and have precisely a couple of minutes to react and take a decision. Go on. Defer your decisions. Ask for soak time. Most of your important decisions deserve at least a night long think time and what you need to do, is learn how to ask for it. Blatantly and clearly.

I wish you good luck.

Neuroscientist around the globe now believe that human beings can be classified into two primary groups when it comes to their sleeping habits and productivity. Some of us are much more effective during the day while others are much more effective at night struggling to get up every morning.

The whole idea of having a common work time where everyone does a nine to six is really counter productive as per this theory, but that is not what this post is all about.

One of the building blocks of the theory that some people are much more effective during the early morning while others are much more productive during the late night dates back to the days where our ancestors were living in the woods and were gatherers.

It is believed that during that rather large number of years of evolution, the human race had figured out how to collaborate better for survival. Each tribe was comprised of typically two kinds of human beings. There was a group that was responsible for getting up early and gathering food for the tribe. Then there was the group that was responsible for staying up late and guarding the tribe against attacks from wild animals.

Years of evolution, morphed the neural pathways of these two groups in such a way that the first group was much more attentive and functional during early mornings, while the other group was much more attentive and functional during late nights. This theory, received a lot of attention in a book called Brain Rules  by John Medina

Once you start comparing the modern day world with it's roots from the prehistoric era when our ancestors were barely getting down the tree and lighting fire,  behaviors or individuals and how the human race might have morphed start making a lot of sense.

Take for instance the classic act of gathering in meeting rooms, sitting around a table and talking at length for hours about what is wrong and how we (the collective we) should fix it. The meeting room is typically filled with two kinds of people:

The First Kind: The young and enthusiastic developer, who is clearly not very comfortable there. He is fidgeting in the chair, looking at his watch to see the time, wondering when the meeting is going to get over, thinking about the memory leak in his code and how he is going to fix it and talking occasionally only when asked a specific question.

The Second Kind: The manager from the best management school in town, who is contributing actively to the discussion. Asking a lot of questions. Dragging the meeting longer, is in no hurry to end the meeting and in all probabilities is going to go and watch you tube videos after the meeting.    

Your meeting is a Bonfire from the Pre Historic Era.

No. Seriously. Dive back into the depths of time. Our ancestors lighted up pieces of wood every night and gathered around it too feel the warmth of the fire. The fire was a symbol of safety. If you were a tribe from those days, who do you think would have liked the idea of spending an entire day and night around that fire?

The gatherers had stuff to do in the morning. They had to catch enough sleep, get up and get out there to get as much food for the tribe as possible. The guarders had stuff to do during the night. They had to catch enough sleep during the day, get their spears sharpened and be on the lookout for wild animals during the night. It was the sick and the old, that loved the fire the most and liked the idea of sitting around these fires for most of their time.

Nothing really changes all that much in the formation of the human brain in just a few hundred years. The fundamentals still remain the same. Look around you and you will discover that the people who enjoy the meetings the most are either incompetent, out of shape, out of touch or not very productive. They are not bad human beings.

They are just the 'sick' and the 'old'' of the software development world. The meeting to them is pretty much the bonfire. It is symbolic to safety, because they can almost never introduce a bug while in a meeting. It is symbol of warmth because nobody every shouts at each other in a meeting. It gives them a sense of belonging because they can now contribute (anyone can give ideas) without having to work really hard for it.

The meeting is their only way to stay connected to the tribe and get a share of the food and protection by the gatherers and the guarders.

The point of this post, was to remind you that if (and I am just saying if) you start enjoying your meetings, you are not gathering food and neither are you guarding the tribe against wild animals.  You are just squatting around the warm and cozy fire expecting your share of free food. Contribute. Do some real work. Even if it is small. The least you can do is, stop enjoying those meetings and stop dragging the rest of the tribe into it.

Go on. Say no to those meetings.

I wish you good luck.

Most organizations seem to have an itch for logging timecards of employees. What time did they enter the workplace? When did they leave? Did they spend nine hours at work? Policing is stupid. Number of hours you spend at work have no direct correlation with your productivity.

If you are starting an organization and have an unending itch for logging something, start out by logging the number of hours everyone in your organization spends on meetings.

Nine programmers gather for a 'quick discussion' which blows from a five minute discussion to a one hour meeting is nine man hours wasted.

Being in a meeting is worse than not being in office. When you are not at your workplace there is a possibility you are working from somewhere else. When you are out having fun, your chances of coming back fresh and putting in more productive hours are high.

When you are in a meeting, we know for sure, you are not working and you are getting drained out.

Of all the things that most typical organizations log or care about (time spent in office, processor cycles, dress code), most things do not have any direct correlation with developer productivity.

Number of hours spent in meetings per day is one Metric however, which does have a strong direct correlation to productivity.

If you are not actively measuring and logging this metric your organization is a classic case of an ostrich burying its neck in the sand.

If you are logging this metric, chances are that the three hundred unproductive man hours that you spent on meetings last month are going to make you lose some sleep, specially when the reports are in your face and that is a good thing. Now its time to do something about it.

That something is not another meeting on how you can reduce your meeting time.

Can a ten minute detailed email do what an hour long meeting would have taken? Can you use screen capturing utilities to do videos to give to the clients instead of getting the entire team to demo a new feature to them? Are there any better ways to capture and pass information than people being hustled into meeting rooms. Ask the difficult questions that you avoided for months or even years.

If you can spend three hours to do a video and avoid a one hour meeting, you should. Videos typically just require one person to create them. Videos aren't intrusive. Videos are permanent and reusable. You are much better better off investing the three hours, rather than inviting ten people in a meeting, interrupting their flow and blowing up the talk time of your organization to ten hours.

Meetings are not just toxic. Meetings are emotionally stressful. Meetings interrupt flow.

So here is a golden rule for your startup: Log your meetings. See how man hours you drain into sitting in meeting rooms and talking and then rage your very own organizational war against meetings.

I wish you good luck.