Coté

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?

Hello there! Let’s be honest, the highly manual-driven newsletter of mine was mostly dead. I stumbled across Revue.co which looks like the exact level of automation needed to make me more successful at sending out newsletters. I’ll try for every few days and first and see what happens. I imported the 107 existing subscribers I had in tinyletter, apologies if you don’t like this shift, feel free to unsubscribe, of course!

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.

A kingmaker in the making. I’ve talked with an old colleague about pitching a developer-based strategy recently. They’re trying to convince their management chain to pay attention to developers to move their infrastructure sales. There’s a huge amount of “proof” an arguments you can make to do this, but my experience in these kinds of projects has taught me that, eventually, the executive in charge just has to take a leap of faith.

Hey, I’ve not only seen this movie before, I did some script treatments: Chief Executive Officer John Chambers is aggressively pursuing software takeovers as he seeks to turn a company once known for Internet plumbing products such as routers into the world’s No. 1 information-technology company. … Cisco is primarily targeting developers of security, data-analysis and collaboration tools, as well as cloud-related technology, Chambers said in an interview last month.

This post is pretty old and possibly out of date. There’s an updated version of it in my book, Monolithic Transformation. In contrast to the way traditional organizations operate, cloud native enterprises are typically comprised of self-motivated and directed teams. This reduces the amount of time it takes to make decisions, deploy code, and see if the results helped move the needle. More than just focusing on speed of decision making and execution, building up these intrinsically motivatedteams helps spark creativity, fueling innovative thinking.

Explained like this, this makes a lot a sense: “When accepting a task, this philosophy proposes immediately allocating time in the calendar to accomplish it. Consider the due date, the time required, and the relative importance. Then book the slot…. This extra step reinforces the rigid time constraint immediately, not later when I’m staring at a lengthy to-do list and wondering where to begin. Each yes to a commitment is an implicit no to another.

Explained like this, this makes a lot a sense: “When accepting a task, this philosophy proposes immediately allocating time in the calendar to accomplish it. Consider the due date, the time required, and the relative importance. Then book the slot…. This extra step reinforces the rigid time constraint immediately, not later when I’m staring at a lengthy to-do list and wondering where to begin. Each yes to a commitment is an implicit no to another.

Explained like this, this makes a lot a sense: “When accepting a task, this philosophy proposes immediately allocating time in the calendar to accomplish it. Consider the due date, the time required, and the relative importance. Then book the slot…. This extra step reinforces the rigid time constraint immediately, not later when I’m staring at a lengthy to-do list and wondering where to begin. Each yes to a commitment is an implicit no to another.