Most of what we do as white-collar workers is help our organization come to a decision. What new geographies to sell our enterprise software and toothpaste in, what pricing to make our electric razors and cranes, which people to fire and which to promote, or how much budget is needed according to the new corporate strategy. Even in the most cynical corporate environment, asking questions — and getting answers! — is the best, primary way to set the stage for making a decision.

One of the more eye-rolling tactics of white collar workers is what I call “fence painting”: an employee somehow gets someone else to do work for them. This can be as simple as coasting off budget, but the more insidious practice is to get other outside your chain of command to do work for you. Most of us have experienced this: days after The Big Meeting you suddenly think “why am I up at 11am working on this report for Scopentholler?

In corporate meetings, oftentimes one person figures out a problem and comes up with a solution. Equally often, multiple people in the meeting like the re-iterate the point in their own words, adding 5–10 minutes more to the meeting. Once the epiphany and decision is made, everyone should just close the issue, and move on. No need for people to comment on it more. For example, in one company I worked for we were discussing a software product name.

I’m always wanting to do a talk or write a series of items on the white-collar toolchain, or surviving in big companies. Here’s one principal about presentations in corporate settings. Slides must stand on their own Much presentation wisdom of late has revolved around the actual event of a speaker talking, giving the presentation. In a corporate setting, the actual delivery of the presentation is not the primary purpose of a presentation.

One of the “tricks” you learn in programming - “soft skills,” apparently they used to call them - is that you should match the style and formatting of the code you’re editing. If you’re starting with your own code from scratch, no problem, go crazy. But if you’re like most developers in the world and maintaining an existing code base with incremental improvements, you’ll more often than not be editing and adding to existing code.