Are your meetings worth attending?

"Remember, kids, your projects are due a week from Monday, so you'd better get started if you haven't already."

This imminently relatable phrase, or one like it, is probably the first exposure to nagging that most of us had outside of the home. Oh sure, Mom and Dad had nagged us for years to clean our rooms, say please and thank you, and wear jackets. But our teachers introduced us to business nagging. I'm using the term "business nagging" to characterize the general practice of nudging people to do things for common professional effort.

If you fast forward to your adult life, business nagging morphs into things like, "don't forget to sign off on your hours in payroll," and, "everyone must update their email signatures to use the company's official font by next week." The subject matter becomes more adult in nature, but the tone and implications do not. When you hear these phrases, you're transported back in time to junior high, when you needed to rely on a teacher to help prevent your general incompetence at life from creating unfavorable situations for yourself.

There's a subtle problem with business nagging growing up alongside of us. As children, we actually are pretty incompetent at looking out for own interests. Left to our own devices, we'll procrastinate on the school project and then pull an all-nighter ahead of turning in something that earns us a C minus. But as we grow to adulthood, we learn these lessons firsthand and wind up being generally decent at looking out for ourselves. We tend not to need nagging nearly as often to do things that will benefit us, so being nagged to do things that will benefit us winds up becoming largely superfluous.

And that leaves the most common form of business nagging: being nagged to do things that offer no obvious benefit to the recipient of the nagging. Signing off on your hours in payroll doesn't benefit you directly (except, perhaps, by removing the artificial threat not to compensate you for the work you've done). Changing your email signature doesn't benefit you directly. According to someone with some degree of power somewhere in the organization, you doing these things will benefit the company. Presumably, if the company benefits, so do you, somehow. But there is as much vagueness in that equation as there are "somes" in the previous sentence. From where you're sitting, it's just bureaucratic procedure having only one tangible benefit—getting the administrator of the business nagging to go away and leave you alone.

Perhaps the most endlessly renewable source of business nagging is the recurring meeting. It lurks in your Outlook calendar like the outrageous cable bill that you've been meaning to do something about. You should probably object or at least question its necessity, but every time it comes, you reason that it's easier to pay the piper than to expend the effort to put things right in the world. You go to the meeting. Or maybe you don't go, and you incur some business nagging: "guys, half the chairs in the department touch-point meeting were empty last week, so people really need to make sure they're going and getting there on time." Why should you go? Who knows. Because chairs were empty or something.

But a curious thing starts to happen if you're at a company for a while. You get assimilated to the culture and you stop asking "why" as much about things that had previously struck you as process for the sake of process. You gain authority and influence via seniority and you resolve cognitive dissonance by reasoning that all of the bureaucracy must have some purpose or else you wouldn't have gone along with it over the years. You inhabit a position to speak about what is in the best interests of the company, and you use that position to make policies, call meetings, and nag people for not showing up.

The creatures outside looked from pig to man, and from man to pig, and from pig to man again: but already it was impossible to say which was which.

-- George Orwell, Animal Farm.

If you're a software developer that's been at a company for a while, you probably have a love-hate relationship of sorts with meetings. It's in our very blood to hate meetings and prefer instead to be coding in a state of "flow." And yet newbies don't get invited to meetings. It's a status symbol of sorts that you're including in the weekly call with management and asked to sit in on all code reviews. And it's an entirely different thing when you call meetings because you're a programmer yourself and the meetings you call are meant to go over important things like build health, coding standards, architectural vision and the like. And since your meetings are important, who do the newbies and grunts think they are to skip them?! You're not calling them for your health—it's not as if you like them!

Should you find yourself in this situation, thinking these things, pause for a moment, and consider the nature of adult business nagging. Consider that people not showing up to the meetings you call is a sign that they don't perceive any benefit to doing so; they don't think you're going to provide anything that will help them do their jobs. Software developers are intelligent people who will optimize to get their work done as efficiently as possible, and they don't think your meeting is helping them toward that end. That's important feedback.

So before you fire up outlook to send out a sternly worded piece of business nagging, it's probably worth asking yourself why they don't see value in attending. And once you've worked out why they don't see value in it, it's probably worth addressing that deficiency. Not only will the group be better for it, but you'll learn things that will improve your chops as a technically focused leader.

This is a guest blog post by Erik Dietrich. Erik is the founder of DaedTech LLC, also an experienced programmer, software architect, team leader, coach, and technologist that enjoys working with a wide variety of programming languages, frameworks and tools. The majority of his recent experience has focused on the .NET framework, though over the years he has worked with C++, Java, and a number of other languages. Projects range from low-level driver and kernel module programming all the way up to user interface design, and the types of applications run the gamut from home automation to rigorous code analysis to line of business applications.