Sunday, March 22, 2020

Remote culture

Fully remote is a culture, not a technique — a company that is not already equipped for it can handle individual contributors working from home temporarily but will struggle to let anyone go completely remote. Tellingly, these organizations almost never support home office work for managers or executives, because their decision making processes rely on face to face.

Those managers and executives certainly do whip out their laptops and iPads at home and on planes, and it’s rare not to find some weekend hours clocked by this group of people. But the work that they do at home is typically solo work: asynchronous communication (long form writing or email exchange) is the majority, and synchronous communications (calls and instant message) are used to handle emergencies or set up a meeting at an office. Organizations have to have processes to communicate information up and down, and to make decisions based on that information. If those processes are built around office meetings, they stop working properly when important team members aren’t present, because remote meetings suck.

I think there’s lot of remote-oriented folks posting about their tools out of a genuine sense of helpfulness, and just as many blank stares on the receiving end. Instead, it would be more helpful to repost Chelsea Troy’s blog. Tools don’t fix people and process problems: the first corporations made do with quill and parchment and sailing ships, while modern corporations fail in the midst of plenty every day (never mind hard times). Extolling different collaboration tools misses the point because it doesn’t address the cultural differences between remote-rare and colocation-rare teams.

Because it is a cultural shift, going from a fully on-prem culture to a fully remote culture over the weekend is not going to just happen without some active and intent work. The good news is that there is now ample incentive to put that work in, because the alternative is to stop communicating or making decisions. Going all the way remote as Coronavirus-driven shelter-in-place orders are demanding is better than the hybrid that is tried in better times, even though it is under duress.

To be clear, I’ve worked equal amounts in remote-first and colocation-first companies, and I think that remote-first companies have a distinct advantage in the marketplace. The advantage is because there’s often more thoughtfulness and discipline devoted to communication practices. Communication processes are clearer, because chance encounters and overheard conversations aren’t a thing. A manager that is used to getting their 1:1s done by dropping by desks or taking a coffee walk will have to pay atttention and think about how to maintain communication with their team.

Decision-making processes are also clearer in remote-first, because osmosis towards a shared consensus is nearly impossible. Executives should take this time to consider how decisions are made; if the final word only happens in a room full of people, that’s going to need to change.

Unfortunately, remote-first is not a panacea, and a fully remote organization can still squander their opportunity. Anti-patterns such as closed-loop communication cells, HIPPO decisions, and analysis paralysis absolutely can and do happen.

Those are all flaws for any organization though; the worst way to fail that is remote specific is to forget about time zones. In order to work as a team, a group of people has to have some common hours for synchronized problem solving. If you don’t have that overlap, then you’ve got multiple teams. Multiple teams can depend on and serve each other just fine, but don’t mistake them for a unified whole.

Saturday, March 21, 2020

Engines and Fuel part two

Why don’t companies make content?

The best answer is that they have decided not to invest (or similarly, have not decided to invest yet). Companies are often aware of the gaps their customers complain about, and yet choose to prioritize other things.

A less good answer: they are not hiring the right people or incentivizing the right behavior, but still hoping or expecting that the content will magically appear. This company may still get lucky if their product is well aligned as a place for partners to work. A vendor with the perfect match of demand and platform can attract and support ecosystem with little effort, much as a flipped coin could land on its edge and balance there.

Next, the company that has hired and incentivized for content creation, but is still unsuccessful because the platform is lacking. Customers and field tech/service partners will use the tools to solve problems, more or less happily, but those solutions are on a black market for the company. Because there’s no official path to share, validate, or optionally monetize, the company is disconnected from its own content. At worst, it can find itself in the terrible position of trying to suppress content built by its own employees. Good news: these are simply product problems, fixable by a product team. Build a safe content development and execution chain and you’ve got an answer.

Finally, the company that has built tools, but cannot find people to use them: I don’t have a lot to say here, because it’s a basic product management problem. The product exists but does not fit the market, so it needs to be changed to do so.

Sunday, March 1, 2020

Finding the Price

Let’s dive once more into the licensing breach! Here’s the background:

What’s not covered? Well, when I wrote this post about evaluating a side business, it came close to the process for defining the price of a cost-plus service or product. That’s not a particularly hard task in theory:

  1. Find the cost
  2. Add a margin
  3. Adjust as needed per your favorite Economics 101 textbook

Of course, this simple approach will provoke sniffs of disdain in most software circles, where the dream is to write code once and deliver it forever. In software, the task is supposed to go like this:

  1. Find the value
  2. Subtract a discount
  3. Adjust as needed per textbook

If your software solves a million dollar a year problem and costs you $5,000 to write, you’ve got a lot of room to negotiate a price in.

Running a successful enterprise of course requires you to think about both approaches, because if you find yourself negotiating prices that are below your cost, that won’t end well.

Furthermore, the Platonic ideal of writing software once and never touching it again is pretty rare; most complex software needs to be continually maintained in order to fix bugs and keep up with changing fashions. This makes cost a little more challenging to determine, as it’s an ongoing function of R&D team size (not to mention support functions, cost of sales, &c).

Even worse, Software as a Service and other, simpler forms of term licensing require you to predict costs and values into the future and spread them out, probably in a way that front-loads your costs and back-loads your profits. In some ways this matches the realities of software development more accurately since it allows for ongoing cost and value increases, but it can also set off a treadmill of expectation increases. That is to say, a SaaS which does not continually improve will not compare well with one that gets gradually more feature-rich and nicer to use. As discussed before you could also use bands or freemium models to disproportionately allocate costs and profits across different classes of users. Or you could aggregate one class of customers into a service that you sell to another class of customers, if you’re feeling particularly Silicon Valley. All of these approaches are just abstractions over the core problem of pulling in more money than you pay out, don’t let them distract you.

So, just like license models, price is deceptively simple:

  1. More expensive than your costs
  2. Less expensive than non-consumption
  3. If you’re going to spread the cost out, make sure that you don’t drop average prices below average costs. 

Glad I could help.