Sunday, August 18, 2019

Everything I know about the IT business is from Godzilla Against Mechagodzilla


Which movie is this? There’s a few, so it’s important to disambiguate! https://en.wikipedia.org/wiki/Godzilla_Against_Mechagodzilla



Not to be confused with https://en.wikipedia.org/wiki/Godzilla_vs._Mechagodzilla (which I can only recommend to the fevered or otherwise hallucinating) or even https://en.wikipedia.org/wiki/Godzilla_vs._Mechagodzilla_II (pretty fun, but not a sufficient scaffold for understanding one’s career). To be fair, https://en.wikipedia.org/wiki/Pacific_Rim_(film) would probably also work for this exercise. Let’s get started!

When problems become apparent enough to need resolution, they’re often all-consuming.



Your old plans for resolution are for your old problems, and might not work any more.



Someone or something is going to take a fall. New attempts to fix this culture are laudable and I hope they succeed.



A new solution is much more likely than fixes to the old solution.



People struggle to put rationality ahead of emotions. This fellow blames people instead of technology for past failures.



New solution projects always have surprises and grow to cost more than anyone expects.



They also still go into the field untested against outside context problems...



... and bad things can happen when testing in production.



Metrics data is fine, but user interfaces should always put the bottom line up front.



Give an analyst an alert, and they’ll want all the data.



Someone always ends up taking one for the team.



Stated differently, if everyone only performs to the stated requirements then the project won’t be successful.



Inelegant solutions need a lot of power.



Partial success is better than complete failure.



Analysts will grow fond of their tools, even if the ultimate outcome was only partially successful.



Tweetise here: https://twitter.com/puercomal/status/1163117265543294976?s=21

Friday, August 2, 2019

Enterprise Business Metrics


So you’ve launched a product... Is the product selling? How’s ASP (Average Sales Price) after discounting? Deal size? Cost of sales? Are there measurable predictors for losses? Are there ways to accelerate or increase the wins? If your license is per term instead of perpetual, is your product getting renewed?

And if your product is one of many...  are your wins correlated with the wins for other products? What would happen if they were bundled? Does your product cannibalize something else the company sells? How would you know? Do ELAs hurt or help your product’s adoption?

Companies ask these questions because they need to manage the business. Tautology, right? So let’s be blunt: you can’t get investment or spend investment without some way to predict how you’re doing, and you can’t decide if you’re going to continue an investment if you can’t see how that investment is performing. As a product leader, your paycheck is coming more or less directly from that investment and these questions have a ring of immediacy to them.

And if your product is a consumer-facing direct sales widget, you may be facing some mysteries (aren’t we all), but the numbers are probably relatively clear. Unless it’s sold through retail partners. Enterprise software sales though... when your product starts at “new car” and can cost up to “Central Park penthouse”, measuring performance starts getting strangely difficult.

Enterprise software is sold to customers who don’t always want to be clear about how much they are willing to pay or when they are willing to pull the trigger. At the very least, this means that the deal data is unclear and may change for reasons that don’t involve your product.

Enterprise software is sold by sales people, and sales people are maximizing their compensation plan and pipeline. At the very least, this means that entering the data you want into Salesforce is pretty low on their priority list. At the extreme, it can mean a variety of bad behaviors, particularly if the sales person is not actually competent. They might have good reasons for sandbagging deals or inflating pipeline, or they might have heard it was a good idea somewhere and misunderstood the reasons... but all sorts of craziness can happen in an enterprise sales team.

Setting aside the truly bizarre behavior of a failing team, sales leadership might try a bunch of mechanisms to deal with the normal lack of clarity. Favorites include:
* Dedicated people who force the deal to make sense. They might be called something like “sales operations” or “deal desk” or “contract specialists”, or the function might be overloaded onto an inside sales team. The resulting organization is simply fatter than before, because there’s still customers and salespeople with their own motivations and context in between the data and the organization.
* Punitive policies: the deal won’t be booked or the sales person won’t be paid if all the reporting isn’t done in a correct and timely fashion. This is an amusing game of chicken because the company willing to a) not sell product or b) risk a lawsuit over a principle of report quality has got their priorities seriously backward. Actually going through with such a threat is a great way to lose customers and sales people, which really reduces your sales numbers.
* Rewarding policies: the sales person will get a toy or points toward the yearly club or public recognition for doing their reporting in a correct and timely fashion. Again, simply amusing, because this data is not worth an incentive large enough to motivate a sales person worth hiring. A good sales person in enterprise software makes very large amounts of money. You can play on their sense of camaraderie and you can ask them to be diligent, but those factors are present without the incentive. In order to incent, the prize has to mean something in relation to their compensation, and that number is not small. Furthermore, the sales person’s job is to make the customer’s organization complete the purchase, and the incentive has no impact at all on the customer. Is it supposed to make the sales person work harder? Then why isn’t it simply paid to them as part of their total compensation? Are they supposed to give the incentive to the customer’s purchasing department? Sorry, that’s illegal bribery.

Given the ineffectiveness of these interventions, why do companies pursue them? Any generalization will miss a lot of examples, but I am fond of two explanations: the manager who is more comfortable with spreadsheets than conversations, and the manager who isn’t sure what to do, so they do something that they understand.

So we return to thinking about what the deal data is worth... there’s a quote popularly attributed to Charles Babbage, “Errors using inadequate data are much less than those using no data at all.” If the data in Salesforce can be considered directionally correct but untrustworthy in detail, it is still useful for the purposes listed above. You can manage with it. You’re working with a string and a rock instead of a titanium yardstick and a laser level, but a lot of buildings have been erected like this. Improving the quality of your sales measurement tools is worth very little when compared with double-checking their results: talking about specific deals with sales people and customers can be remarkably illuminating.

Working with a Coach

Executive coaching and mentorship is an interesting part of modern business, and sometimes people are not prepared for taking advantage of it. Here are some notes on the purpose and value.

So you’re working with a coach to get better at execution... what are you going to say?

As a potential mentee, start with outside boundaries, the Overton window. A corporate coach is not a therapist; the need is to find performance problems and optimize teamwork. More Dave Righetti, less Sigmund Freud. You may uncover reasons to work with a therapist, because leadership work involves you as a person far more than individual contributor work does. Your emotional resources are going to be used when you lead, inspire, console, and support others. The coach is not the person to help with personal maintenance, but they might be able to show you what you need. Fixing those problems is work to do elsewhere.

Within what you’re willing to discuss, locate the secrets. Why don’t you want that opinion known? Is the reason rational and explainable to an outside coach? Is that reason a you problem or an organization problem?
Ideally you’re not trying to discuss anything that your team couldn’t already know, and the question is how to be more effective in communicating your thinking, persuading others to agree, or accepting that your opinion didn’t prevail and the team is going elsewhere. If the situation doesn’t look like that, there’s something to fix. Is it you, or is it the organization? Is it reconcilable, or will it end in parting ways? Might as well focus on figuring that out before you bother with unpacking whatever secret has led to this realization.

Now, back to the coach. This person fits into one of three boxes: A mentor who is helping you for charity and their own growth, a coach that your organization paid for, or a coach that you paid for.

Mentors may or may not be encouraged by the organization, and there may or may not be a formal mentorship program; in my opinion those parameters only affect the degree to which the mentor is actually willing and able to help. A mentor who is able to see problems and help you fix them is helpful, regardless of what structure the organization provides or does not provide. Notably, a mentor’s time is limited and you need to aim for efficiency. If you don’t have a specific and achievable improvement goal in mind, you’re not getting mentorship, you’re having coffee with a coworker.

The existence of an organization-paid coach may open some questions: why is this person assigned to me? Are they being hired for others as well, or am I singled out? You may feel like you’re being prepared, for greatness or for unemployment. It’s best to assume this is a positive investment on the organization’s part in order to make you (and potentially others) a better leader. There is little to be gained from indulging in paranoia. However, it is fair to note that a person hired by the organization has loyalty to the organization as well as to you. You should think, and communicate with the coach, about what information you are willing to share. Again, time is limited, but you probably don’t know what the budget is; it’s best to get what you need fast.

A coach that you pay opens a different kind of risk: they are potentially seeing the organization through your eyes alone. Even if they’re able to attend your meetings as your guest, they are always getting a filtered experience. Ideally the fact that you’re paying will help you focus, but that’s not always the case; you should plan for a fixed number of sessions up front and clearly state your immediate and achievable goal.

A good coach will see small and large blockers, and they’ll sound trivially obvious. You may even already know you have these issues. “Discussing the problem and constraints first is good for engineers, but bad for executives; start with your proposal instead of how you got there.” “Don’t cross your arms and look away when you’re asked a question, you look defensive.” It’s not helpful to discuss the existence of the blocker; move on to their recommendation, and sincerely try that recommendation at least three times so you’ll know if it was the right thing.

Bad outcomes can occur in mentorship and coaching, but by far the more common result is an ineffectual series of meetings. If the mentor is unable to provide helpful advice, or if the mentee is unable to act on the provided advice, or if the actual problem is outside of the mentee’s control, then coaching is really only relevant to a future situation where the mentee is hopefully able to use what they learn.

Sunday, July 28, 2019

Team Scars


You know those signs in every shared kitchen? “Please rinse your dishes and put them in the dishwasher”, “please don’t leave food in the fridge over the weekend”, &c? They happen because people were piling dishes in the sink and letting food rot. Something had to be done, and the sign was the result. You may meet people that are imagining signs like that around unexpected aspects of their work. It can be surprising because these signs are invisible.

“Ticket validation should be a separate stage in the workflow”. Why? Why not? This isn’t an objective proposition, it’s reaction to shipped bugs that more careful validation might have caught. So a manager adds a step in JIRA... which is completely pointless unless the team agrees to actually do more testing. Just as likely, the developers now resolve and validate where they used to just resolve, without changing anything on shipped quality. Dang, the kitchen is still dirty! So maybe a developer speaks up.

“Please write unit tests for all of your code,” says Alice. She’s sick of being on call for dumb logic errors. Like washing the dishes, this is a shared code hygiene issue, and hard to argue with. A unit test is an alarm that the code might no longer be working as intended. It costs little, and it’s helpful. A policy that you should have one at check in? That’s a helpful reminder. But a policy without enforcement is really a guideline, so maybe Bob wants to talk carrots and sticks: But now there’s resentment, because Charlie doesn’t agree with the goal. Worse, they may be right.

Each team member brings their past experiences to this conversation, and can easily spend a lot of time talking past each other. I’ve had one very bad experience and several mediocre ones with test-driven development teams, so I’m biased against the concept even though I appreciate the theory. I have to focus on being constructive and evaluating each new proposal for TDD on its own merits.

That’s how to do the job... what about who’s doing what job? Defining the actual roles that team members are going to play is an even bigger minefield. “Product managers should be technical enough to engage in code reviews” ...or is it “Product managers should be so non-technical that they can’t follow the standup”? “Teams should have dedicated quality assurance engineers” versus “Developers should take full responsibility for code quality.” There are software people out there who’ll passionately argue for any of those statements. That passion might come from recently reading an Agile textbook, but it’s more likely to be from remembered experience. “Darlene was really helpful, she’d even fix bugs between customer calls!” “Eddie was kind of a seagull, but he was too scared to bother us much so that was okay.” “Frankie gave clear direction and then got out of the way.”

As long as someone is doing the various tasks that need doing, the team can still be successful no matter what. But the larger organization wants to see repeatable results and clear accountability, so it’s not great to have paper PMs writing code while paper engineers define requirements. Furthermore, in software culture the work occupies most of our time and headspace. Our job function and personal identity can become tightly interwoven, which makes questioning of that function feel like an attack. “What would you say you do here?” Sometimes a well-intentioned role re-definition leads to angry resignations, as when a field engineering team is asked to do more consultative selling and less field repair work.

What to do and who will do it. These are all people problems: mental models that need communication, a shared consensus that needs building, a plan that needs to be followed. The only way to get there is to talk it out. Woe betide the team imagining one-size-fits-all technical solutions.

Sunday, June 16, 2019

Changing the Company


I’ve written a bit about mishandled change attempts — everyone loves a little schadenfreude, and failure is easier to spot than success.

This does not mean I think it’s wrong to change: you can’t keep selling buggy whips or spellcheckers when the market for them disappears. Let’s set aside the strategic question of recognizing that the need for change is there: it’s somewhat data driven and somewhat emotional and a huge topic on its own. But tactically speaking, once the decision is made, how to proceed?

First, an inflection point must be identified. Can the current business remain profitable long enough to keep the company alive while the new business starts up? If yes, then you’re planning for a relatively smooth transition. The new business takes off, the old business lands, management feels profound relief and it’s high-fives all around.

Product: If your company can gradually transition into a new form, then launching new products is a great way to get there. The most obvious example of transformation via product is Apple. Famously vertical, Apple has gradually shifted from computers to music players to compute appliances, but always from the same brand and always offering the same core value proposition. Amazon Web Services appears to be on a similar trajectory. If their original business of rented server instances sunsets in favor of pure server-less, it would be a smooth transition and represent very little change in the vendor-customer relationship.

Business unit: If a more intense change is needed, you may need to start the new business as a separate vertical unit. Microsoft has been fairly successful at this with Azure, while many others have done worse (such as Intel Online Services). A business unit is ideally a separate business. Some fail to actually separate, and remain dependent on the parent until they fold back in. Some fail because they blatantly compete with the parent instead of outside challengers. A successful business unit helps its parent to produce a new business. Azure is a good example of this — it enables Microsoft to continue selling the same value chain into a changing enterprise marketplace. The same approach can be seen in enterprise software companies that sell their products as a managed service, such as Atlassian.

If the window for change is too short though, and the company can’t survive on existing products, then you’re planning for a rough ride. “Any landing you walk away from is a good one” in this case. Company wide transformations mean stopping the old business and starting a new one. There are not a lot of examples of success, but one really stands out: Netflix pulled this off, after a nasty misstep. Good luck if this is your situation, I’d love to hear of another success!

Wednesday, June 12, 2019

Multi-tenancy in platforms

If you’ve built a monolithic enterprise product, it is not sensible to convert it to multi-tenancy. You can sell a managed service provider (MSP), but you’re not going to get to software as a service (SaaS).

Often no one wants to discuss reasoning at all, because the need to convert your business to a different model is taken as an imperative which overrides any reasoning. Present problems are ignored, because the future state is too valuable to ignore. Unfortunately, “skating to the puck” in this case is leaving the rink, and the result looks like disrupting yourself.

But what about customers who demand multi-tenancy? There are very few customers who actually need multi-tenancy features. Let’s take a moment to clarify what these features are, because a lot of folks confuse multi-tenancy with role-based access control (RBAC).

Multi-tenancy lets you operate a single instance of a product for multiple groups of people, keeping content, capabilities, and configurations hidden from users who aren’t members of the correct group. Multi-tenancy features allow for a super administrator who can configure which tenants are part of which environments. They allow for tenant administrators who can configure which users and groups are part of a single tenant. They allow for tenant users who do the job that the software is for.

Most customers do not need multi-tenancy features for themselves, they need to be tenants and they hope that the vendor is using modern cloud techniques to deliver features cheaply. Maybe they want administrivia to be separated or hidden away so that the result is delivered as a service. This doesn’t mean the customer wants multi-tenancy. It means the customer wants your software as a service.

The exception is the customer who plans to provide your software to their own customers as a service. This customer does want multi-tenancy features: they want to manage the access rights of business units A, B, and C. This customer is not going to be happy with a stack of singleton instances of the software. This customer needs a professional services development partner, or perhaps a different software vendor. They are asking the vendor to sell a product that allows configuration and maintenance of a multi-tenant environment.

The whole conversation rests on an assumption that the resulting software environment will be simpler and cheaper to set up and use than a stack of singleton instances. I see no evidence for that assumption when the software in question was not designed from the ground up as a multi-tenant application. It’s far better for the vendor to offer their software in singleton mode as a managed service. This effort will inevitably produce the tools necessary to support and automate software installs, which the company can decide to sell to selected customers if they like; but those tools do not need to be exposed to all customers.

Sunday, June 2, 2019

Why is open source content rare?

Open source community incentives are biased to prefer developers over content creators.

Open source communities are particularly prone to this failure mode. After all, the developers in the community are all doing their work for valid reasons, so why wouldn’t content creators join them? Hot take: the incentives are different.

Open source development is a resume-building value add for the developer. They’re publishing concrete proof of their ability to write working code. In some cases that code even solves interesting problems. In the best cases the developer is proving that they can work in a distributed team.

This effect continues for a dedicated developer writing content, but that developer isn’t always in a good position to write content without the help of customer-facing consultants, engineers, and analysts.

The social reward of providing quality content is not the same for a developer as that for providing quality code. You might think this is driven by a technical difference. Isn’t writing a configuration file or a test file easier than solving an engineering problem in a compiled language?

Well, maybe. For instance, writing content that reliably and optimally finds all of the vulnerable Java engines across an entire organization is far harder than any whiteboard coding test. (Hint one: a JRE doesn’t have to be registered with the operating system in order to operate. Hint two: crawling the file system is very costly. Hint three: you can’t rely on OS indexing features being enabled.)

 Worse, the risk level is higher for the developer writing content: the content is an incomplete starting point, the user has to learn more to be successful, and the failure potential is increased. So the developer’s risk-reward ratio is skewed away from writing content and towards writing engines.

What about professional service consultants? Don’t they spend every billable hour writing content? They sure do, and billable is the key word there. They’ll only release their work to open source when it’s no longer a competitive edge: too commonplace or esoteric to be regularly valuable. Again, misaligned incentives blocking open source content.

Twitters