startups and code
startupsandcodeStartups And Code
ResumePodcastNewsletterBlog

The Angry Developer - Corporate Etiquette

← Back to home
PreviousNext

I have wanted to post a rant, but worried about how it would be received, how it would affect my career growth, and how it will be taken out of context... With all of that said, it's time.

It will be simple corporate etiquette that I am guessing is never taught or is not as intuitive as I thought.

Don'ts

  • Don't schedule a meeting an hour before the meeting
  • Don't cancel a meeting after the meeting started
  • Don't invite 50+ people to a meeting when only 4 people will contribute
  • Don't start a slack channel, talk about the product, and realize the developers are not in the channel
  • Don't be late, ever. If you are on-time, you are late. (we all will fall short of perfection, but that is the goal)
  • Don't schedule meetings at 5pm and say it will be real quick
  • Don't assume you know a fix is "a quick change" when you have never coded in your life
  • Don't schedule an 8am meeting for Monday at 10pm on Sunday night
  • Don't spend more than a week on a presentation, you should deliver information quickly
  • Don't create a process that creates work or meetings. Process is used to simplify not complicate

Do's

  • Do wrap a meeting completely 5 minutes before actual time to allow for transition
  • Do attend meetings that you will contribute to
  • Do decline meetings that you are attending only for visibility, and not contributing
  • Do schedule meetings at least one business day in advance
  • Do deliver information succinctly, always try to use the fewest words to convey the complete message
  • Do create an agenda for every meeting with goals
  • Do identify deployment, scalability, security, and testing early on
  • Do be honest in meetings, don't just say yes because it is group thought.
  • Do have a single point of contact for a client (backup only for vacation or sickness)
  • Do trust your employees to do their job, if they don't correct that behavior.

Hierarchy of Communication

There should be a hierarchy of communication... I remember back in the day my Jujitsu instructor had a saying on his wall that said this:

Do not hurt where holding is enough;

Do not wound where hurting is enough;

Do not maim where wounding is enough;

Do not kill not where maiming is enough;

Do no unnecessary harm

In communication I would revise it like this

Do not email when slacking is enough;

Do not call when email is enough;

Do not meet when a single call is enough;

Do no unnecessary communication

Yes, a meeting is equivalent to killing in the previous quote. I know that people communicate differently, there are narrators, there are emailers, there are face-to-face people. I get it. However, even in all of those meetings and those discussions, I always here we need specific answers, and then they go on telling a story how they handle this situation before.

Past experiences does not guarantee future performance

Yet, we always try and recreate the exact same situation that was successful. That won't work. What will work is to prepare to handle a new situation as it arises and adjust accordingly. That is what makes projects successful. Experience only informs on how to present options when a new situation arises. Every situation is different.

I'm going to stop for now.  Go build something amazing, don't just talk about it, meet about, investigate, brainstorm, but BUILD IT AND RELEASE IT!

PreviousNext