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.
You have to be careful, however, of how many questions you ask, and on what topic. If you ask too many questions, you may find that you’ll just create more work for yourself. Before asking just any old question, ask yourself if you’re willing to do the work needed to answer it…because as the asker, you’ll often be tasked with doing that work. We see this in life all the time, you ask someone “want to go to lunch?” and next thing you know, you’re researching in all the restaurants within five miles that have gluten-free, vegan, and steak options.
I’ve seen countless “staffers” fall prey to this in meetings with managers who’re putting together plans and strategies. The meeting has spent about 30 minutes coming up with a pretty good plan, and then an eager staffer pipes up and suggests 1–3 other options. The manager is intrigued! Quickly, that staffer is asked to research these other options, but, you know, the Big Meeting is on Monday, so can you send me a memo by Sunday morning?
In some situations, this is fine and expected. But in others, conniving management will just use up as much as your energy as possible: it’s always better to have done more research, so why not let that eager staffer blow-up their Saturday to have more back-up slides? Co-workers can also let you self-assign homework into burnout if they find you annoying: you’ll notice that when you, the eager staffer, pipe up, they go suddenly quiet and add no input.
As always, you have to figure out your corporate culture. But, just make sure that before you offer up alternatives and otherwise start asking The Big Questions, you’re read to back up those questions by doing the extra homework to answering them yourself.
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? I don’t even work in that division!”
What you, the whitewash-encrusted white-collar worker want to do here is somehow still seem “up for anything” and fully capable, and yet not end up painting Scopentholler’s fences. I suggest assigning “homework” as the first rung of filters. If someone wants your input, or wants you to somehow get involved in a project, come up with some mini-project they need to do first. Have them write a brief for you, put on a meeting to bring you up to speed, do a report about how the regional sales have been going, or otherwise force them to do some “homework.”
Assigning homework does two things:
I’ve seen assigning homework cut out a huge amount of fence painting work, for me and others I’ve observed doing this. Also, once it’s known that realize you assign homework, people will stop preying on you: “oh, don’t ask Crantouzok to get involved, you’ll just have to make another deck before she lifts a finger!”
Of course, if you’re pure of heart and mind, you can always just be direct and say “that’s low in my priority queue and not really my responsibility.” But, as with all thriving in BigCo tips here, first make sure the BigCo you’re working in is equally pure of heart and mind.
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. The project had been called “APM.” But it turns out, it wasn’t an APM product, it was just exposing instrumented metrics in the software. This is, in itself, incredibly valuable, but not full blown APM. Someone initially pointed out, “we shouldn’t call that APM,” and everyone agreed.
Then 3 other people chimed in with their retelling of this point, basically embellishing and rephrasing the point. In most corporate meetings, and I’d argue in the never-ending meeting of Slack channels and email, there’s no need for all that extra talk after a realization and decision is made. Someone needs to pipe up and say “what’s the next issue?” or close out the meeting.
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.
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. Instead, a presentation is used to facility coming to a decision; usually you’re laying out a case for a decision you want the company to support. Once that decision is made, the presentation is often used as the document of record, perhaps being updated to reflect the decision in question better.
As a side-note, if your presentation doesn’t argue for a specific, “actionable” decision, you’re probably doing it wrong. For example, don’t just “put it all on the table” without suggesting what to do about it.
Think of presentations as documents which have been accidentally printed in landscape and create them as such. You will likely not be given the chance to go through your presentation from front to end like you would at a conference, You’ll be interrupted, go back and forth, and most importantly, end up emailing the presentation around to people who will look at it without you presenting.
You should therefore make all slides consumable without you being there. This leads to the use of McKinsey titles (titles that are one-liners explaining the point you’re making) and slides that are much denser than conference slides. The presentation should have a story-line, an opening summary of the points you want to make, and a concluding summary of what the decision should be (next steps, launching a new project, the amount needed for your budget, new markets to enter, “and therefore we should buy company X,” etc.).
This also gives rise to “back-up” slides which are not part of the core story-line buy provide additional, appendix-like information for reference both during the presentation meeting and when others look at the presentation on their own. You should also put extensive citations in footnotes with links so that people consuming the presentation can fact check you; bald claims and figures will be defeated easily, nullifying your whole argument to come to your desired decision.
Also remember that people will take your slides and use them in other presentations, this is fine. And, of course, if successful, your presentation will likely be used as the document of record for what was decided and what the new “plan” was. It will be emailed to people who ask what the “plan” is and it must be able to communicate that accordingly.
Remember: in most corporate settings, a presentation is just a document that has been printed in landscape mode.
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.
To make the code easier to read and understand (a broader, high-level goal of programming) it’s best to figure out and match the style being used already in the code. In contrast, you could do things in a different stye - use closures and callbacks instead of more procedural things, or two spaces instead of two tabs, etc. Young programmers struggle with this: like skateboarders, they want to try new tricks and show them off. The code becomes more confusing, harder the understand, and thus more error prone (someone added code without fully understanding what was going on), and slower to change (it takes a long time to understand).
So, there’s that: code in the style of code you’re editing.
In the white-collar world, this same problem exists, except it’s PowerPoint and Word documents, not code. Many “young white-collar workers” I encounter don’t adapt to the existing style too well. They go off and do their own thing, often not consciously. Successful work documents typically follow a very tight pattern (sometimes called a “loop” in slides) for all the same reasons that you want your code to have a consistent style.
Once you’ve figured out and started using the style of an existing chunk of text or slides, the next stage of knowing what the fuck you’re doing (pardon the jargon, a technical term in cube-land) is to project out how that style would apply to entirely new parts of the subject at hand. Did your boss just ask you to “go fill in that those pages on AsiaPac - you know, like 4 or 5 pages”? What she means is “figure out the style and pattern we’re using in the other 20 pages of the report, and do exactly that…and if you can’t figure out the pattern…why am I paying you so much? In fact, if I’m telling you this, why am I paying you so much?”
As it goes with so much of white-collar work, your job is to ensure that your boss doesn’t have to tell you how to actually do something.