Quite surprisingly, I recently spent some time during my workday writing down what I called the “basic responsibility & communication principles.” In my case, they apply to a software engineering organization (and a software engineering outsourcing organization, at that). But I don’t see why they can’t be applied to any other organization where people gather in teams to work on tasks and projects. I present these principles below in the hopes of getting some feedback from the occasional readers of this blog. I personally see these principles as obvious and natural, but that’s just me. It’d be interesting to see if others agree that they are truly universal.
I took the time to write them down after a couple of nasty cases where I was quite surprised when some people didn’t follow these principles and, what’s more, didn’t even feel any guilt about it (and that’s my motivation for listing them here: to see if I’m just a crazy guy with obsolete communication standards.) Now, I don’t expect anybody to be perfect (I don’t follow these principles perfectly myself, but I honestly try). But I at least expect people to recognize what’s right and what’s wrong and to not be surprised if they are questioned or (God forbid) criticized when their behavior deviates from what is considered acceptable.
The Principles
Commitments
- If you promise something, do everything you can and then a bit more to keep your promise.
- The fact that you made other commitments and they prevented you from keeping this one is NOT an excuse.
- The fact that it’s the end of the business day already is NOT an excuse.
- When in doubt, it’s better NOT to commit. Once you make the commitment, it’s your personal responsibility to keep it. You can’t delegate it to anybody else, and you can’t let other people decide on your behalf.
- When you are overloaded, it’s not sufficient to agree about postponing tasks with your boss. If you have to postpone something, at the very least, let people know that you will not be able to keep your commitments. Do it personally and humbly. Yes, it is YOUR fault, and you SHOULD at least apologize, even if your boss told you to work on something else instead.
- Yes, commitments to your co-workers, subordinates, and people from other Auriga departments also DO count. You shouldn’t only worry about keeping your promises to your client and your manager.
Definition of done
- It’s only done when the person who gave you the task ACCEPTS your results. Just because you’ve sent the results doesn’t mean it’s done.
- Always define the acceptance criteria/procedure for everything you commit to.
- It doesn’t need to be formal (“You’ll review and give your ok” is enough).
- Sometimes, the acceptance criteria are (almost) empty: If you promised to send a draft, you probably don’t need the review to mark it as “done.” In this case, just sending it and going home is ok. But you need to agree on that with the person who gave you the task when making the commitment.
- But if you promised to send the final version of something today, it is not sufficient to send the results at the end of the day and go home. You have to wait and verify that the results have been accepted first.
- Always define the list of deliverables for everything you commit to. Will you send an email with a list, or do they expect a nicely formatted PDF? Do you need to send a doc, or make changes in the information system/code, or just call and provide your thoughts over the phone? If you do one thing, and they expected something else, (1) you didn’t do your job well when defining your commitment (and, yes, that’s YOUR problem) and (2) you are NOT DONE yet and should continue working and pushing to do what was expected by the deadline (and, yes, that’s also YOUR problem and responsibility).
Avoiding silence in communication
- If you don’t understand something—ASK. Don’t assume that since you didn’t understand it, you can silently ignore it. It’s NEVER ok to silently ignore.
- If you disagree with something—SAY SO. But don’t expect that the fact that you communicated your disagreement makes it automatically ok to ignore the task. In many cases, it is still your responsibility to do what was requested even if you don’t like it.
- If you need somebody to do something, explain all the important details, and make sure they understand and commit. DON’T treat silence as a sign of understanding & commitment. Get an explicit “yes.”
- If somebody asks you a question, ALWAYS answer. In some cases, all you can say is that you don’t have an answer right now and that you’ll look into it later. In such cases, this is your answer. Deliver this answer to the person who asked the question; don’t keep silent. And, yes, that becomes your commitment to give a proper answer in the timeframe that you specified.
Now, what do you think? Are these principles universal enough? Do you use the same approach in your day-to-day communications?
I was actually extremely surprised that somebody didn’t see those rules as self-evident, because I used to pride myself on the fact that I worked at a company that utilizes the “boutique shop” approach to software development. We don’t provide teams of hundreds of engineers, but we truly focus on the important aspects of engineering, which mostly turn out to be non-technical in nature. And communications is the king of all those non-tech “soft” skills needed for reaching success in the software business. I already devoted one of my posts this year to that topic, so I won’t spend time here describing my opinion.
So, you’d assume that in a communications-oriented organization, understanding those basic communications rules would be a given, right? It turns out, wrong. We spend time on advanced communication techniques and role-playing games, do other stuff, but sometimes forget about teaching the basic values and principles. And since despite all our efforts, we still grow (joking, of course—we have nothing against, and even look for, good growth, provided it is done right), new people come to the organization, and some of them clearly come from a different culture. So we shouldn’t forget about the basics.
At some point, when thinking about that, I went as far as considering if that’s yet another hyped Gen Y thing. After all, one of the people I know, being Gen X as myself, jokes that “You can’t trust anybody who was born after <a certain date> in 1977,” with that date obviously being his birthday. “And if you trust them with any task, you’d better remind them and check the status every day, or you get nothing.” Well, I don’t think that’s true. I personally have a much higher opinion of Gen Y’ers. After all, I’m a proud father of two boys of school age, and compared to them, Gen Y’ers are a bunch of angels dancing on the head of a pin.
But enough jokes (I hope you got that I was kidding, right?). In my opinion, the lion’s share of that hype of Gen Y’ers being less responsible, less loyal to the employer, and so on is caused by the fact that, at least in our profession (software development), they now tend to occupy the majority of standard positions (if you need a software engineer with five to seven years of experience, he or she would probably be born after 1980). And since every generation has its share of black and white sheep, and Gen Y dominates in terms of the number of people being employed in our organization, every time you face a problem with an employee, the chances are good that it’s one of them.
So, it mustn’t have been a difference between the generations that caused the difference in the core responsibility & communication principles. It must be something else. Or it could be that those principles are not as universal as I think. So I’m very interested in your opinion and your core principles that you subconsciously universally expect from others.
