Sunday, September 20, 2020

Proving a Negative

Proving a negative is a tautological impossibility right?

That’s the security business. Prove that you haven’t been hacked. Of course, many vendors realize this is impossible. Fact is, it would require the customer to understand everything they do in total detail so they could call out what was bad behavior. Once again, impossible.

What else could be described this way? Quality Assurance. Prove that the software doesn’t have any unacceptable bugs. Maybe you dedicate people to this function and therefore spend the fixed costs of a sub-department with its own bureaucracy, or maybe you ask developers to spend time on it and therefore move at half speed. Maybe you strike a balance somewhere down the middle. Or you could outsource testing, either to a paid third party or your paying second party. No matter what, you’re more hopeful than certain. Sounds a lot like security.

Security vendors and thought leaders can just flip the argument: you can’t prove you’ll catch the incident of hacking, so we’ll focus on finding bad activity after the incident. Assuming the malicious actors will stay in the system as long as they like and take what they can, there should eventually be a misstep that the security team can see. Still proving a negative, but it’s tipping the scale in defense’s favor a little bit.

What’s the QA equivalent? Fuzzing comes to mind, though there are certainly humans who bring an artful chaos to their manual testing. Long term monitoring of systems can also uncover funny bugs.

In both cases, there is an argument to be made that the cheapest way out of an impossible situation is to buy insurance. The argument goes: “We can’t prove we are free of risk, so we’ll just do the minimum of due diligence for compliance and buy risk coverage.” Or from a vendor perspective, “we’ll offer a cyber warranty that we did due diligence, and caveat emptor past that.”

I am pleased that the majority of organizations I’ve worked with as a long term software monger have been motivated to act beyond the bare minimum. Whether working at a customer or vendor or partner, people want to have some pride in their work. Corners are going to be cut sometimes, but tech debt gets paid down too.

Sunday, September 13, 2020

Conference Giveaways

Remember going to conferences?

When I was a young sales engineer and going to my first conferences, it was clear that an attempt to attract visitors with a freebie or a lottery for a big thing was a strategy. Maybe not a great strategy, but there it is. Notable factors: the thing should be something that the audience would like, and a thing that’s portable for the flight home, right? Computer parts, personal electronics, lightweight clothing. Some link to your product is nice, but slapping a logo on a small toy is fine too. I fondly remember the rubber duckies in space shuttles that the customers threw into the conference center‘s fountain until it was jammed full of them and the organizers came to yell at us. Or the poor guy trying to give away Zunes who had to keep explaining that it was a thing like an iPod. If you’re really desperate, you could just give away software licenses, I suppose.

But the funniest, most bizarre conference give away I’ve ever seen was at one of the first conferences I supported. There are many overlaps between tech conferences and hurricane warning season, something about cheap conference center space I suppose. Imagine if you will, a business casual event in Miami in August with a tropical storm deciding what it wants to do a few miles away. It was hot and miserable, and the conference center was surrounded by construction that helped to keep people away. The sales critter felt that a really interesting draw would be needed. And so, a little unclear on the parameters and yet technically correct, they tried to raffle off a stack of Omaha steaks at a tech conference. 

Traffic was low. We were pitching a service that the already small audience wasn’t very interested in. And so we had plenty of time to stare at this decision and think about it, chatting with the occasional puzzled conference goer who would stop by to ask why we had a pile of vacuum packed meat in the booth. “Shouldn’t that be in a refrigerator or something?” Good question. Seems the sales critter thought that vacuum sealing was sufficient to stop spoilage. (It is not.) Some of those people would stop and chat about grills and cookouts, conversations that never went anywhere close to business.

Sometimes I think of that when people pitch their conference ideas — a couple of dozen chunks of plastic wrapped meat in cardboard boxes piled on a tiny podium in a half-empty conference center, zero connection to the intended purpose. Could be far worse though, one of these days I’ll write about my experiences with team building in the late 90s.

Monday, September 7, 2020

Consulting’s Bad Rap

 


Naming no names... but there’s a type of management consulting shop with an unsavory reputation among middle managers and individual contributors. Let’s look at how the reputation is earned: by training to a model that produces failure as often as not, but always successfully deflects blame.

It’s easy to find problems, and easy to sell impractical solutions to those problems. A lot harder to execute, but if you can deflect blame for unsatisfying outcomes, there’s good money to be made for a very long time.

The model is: interview, sell, train, disengage. In another post, I’d like to go into the outsourcing services variation of this model, but today’s focus is on management consulting.

Interview playbook goes like this:

  1. find the bright and moderately disgruntled. No organization is perfect, and there are respected voices with wasted cycles in every team, observing imperfections and thinking about alternatives. If they’ve discussed these ideas, they may also feel resentful or unheard. The consultant’s job is to find them and amplify their feelings.
  2. unify a group of them behind an idea. There will be a common thread or cluster of complaints, just keep digging until it appears. Remember, the most consulting friendly problems are actually problems with people communicating, so look for breakdowns between teams: process gaps, slow transactions, rework from mistakes.
  3. document and present. The artful step is now to make the problem you’ve discovered seem generally soluble, something that other organizations have faced and conquered. We need a deck chock full of industry statistics, colorful graphs, and quotes from your own organization’s respected voices. The kill slides will present estimated losses from the discovered problems.

Enterprise sales is a two-step operation: produce desire, then conclude the transaction. 

Sales playbook goes: 

  1. As my first sales weasel explained it, “find their pain”.  The interview process and presentation have produced the desire, but a good salesperson will double check that this hook is set. In consulting sales, they’re also hunting for the internal stakeholders who will champion this project, sign the purchase order, and consummate the sale.
  2. magnify the problem. Steve again: “jam your thumb into that pain and twist it around”. The salesperson is working to produce a compelling call to action, a feeling that opportunity is going to pass the organization by. The clock is ticking. How much longer can you afford to let this problem persist? “What’s it going to take to put you in a Cadillac today?”
  3. offer tools and procedure. “Sell ‘em a bandaid.” And now we are back to the consulting side of the house: what is the deliverable that the customer organization will actually get?

Suddenly our analysis deck has returned as a set of recommendations for proposed changes! Process, tools, re-organization, and suddenly your creaky old org could be shiny and new. What if you simply did better?

Some notably missing bits in this deck: 

  • why will people start behaving differently than they have in the past? 
  • How will the organization adopt this tool, process, or organizational structure without stopping the revenue stream?  
  • how will we get clean data to drive the KPIs or OKRs we’re expecting to improve?
  • do we have room from customers and competition to make this change?

Perhaps these questions are asked. Perhaps there are answers. Maybe your organization pulls back from the proposal. But if it does go forward, the next link in the chain comes into play.

Training playbook is wheels within wheels... it goes:

  1. let’s get started! The consulting leaders and consulting  juniors meet with the organization to plan. How will the proposal be made real? Typically by reduction of scope, hand off of the hard parts, and distracting preliminary projects.
  2. let’s do some stuff! Once a regular cadence of activities is established, the leaders vanish and some even more junior juniors are brought in to fill the gaps. Software is purchased, presentations are given, teams spend weeks in training and reforming to their new organization. Critically, this is where responsibility is handed from the consulting firm to the organization, if that wasn’t already clear.
  3. book-cooking. Now it’s time for another deck, showing that progress was made. Numbers, charts, at least flat with hints of improvement if not rocketing skyward. This one will be delivered by the internal stakeholder who bought the consulting engagement, finishing the process of tying their reputation to the consultant’s work. Project better work out, because bills are getting paid and other work has been impacted already.


And now, disengagement... can’t guarantee that the internal organization will be successful at this change they’ve taken on, so it’s only in the consulting team’s best interests to make some distance, and give that little fledgling project room to leap from the nest! Maybe it will succeed - after all, there’s a motivated internal champion now, possibly with a job on the line. Maybe it won’t... but the magic lies in this statement: the consulting organization is no longer connected to the project’s outcome. It’s all on the organization to sink or swim. Meanwhile, there’s another problem to investigate...


How does this model continue to find customers? Shouldn’t the marks dry up? Well, it’s a deeply interconnected web in the enterprise...

  • Appearances matter: like the mark in three card monte, the customer stakeholders left holding the bag are easily convinced to hide their mistake, or even shill with a good reference. Mixed with the base of customers who actually have a good outcome, these voices overwhelm the bitter complainers.
  • Pressure from above: the consulting organization may have pull in unexpected places, making their selection for projects a foregone conclusion
  • Potential opportunity: relationships matter, and the consulting organization could be a vein to recruit from, or a place to jump to in the event of hard times.

And so, there’s good money to be made selling clothes to the miners.

Wednesday, July 1, 2020

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.

Friday, February 28, 2020

Metaphors

I love words. I love to read and write. I was an English major for a reason.

As I implied in that post, it’s important to know how to use language to engage emotion. However, you also need to know when to use a particular tool and when to leave it in the box.

I used to work with a very successful CEO and CMO who would both, when feeling feisty, smack down any use of metaphor or simile  in a presentation.
  • “We’re trying to put ten pounds in a five pound bag”
  • “Support is drowning in priority one issues”
  • “Everything is coming up roses and these are our salad days”

I can still hear “just say what you mean!” in the back of my head.

  1. It is incredibly disconcerting to be forced out of flow and into analyzing your own sentences while you deliver them, so the lesson sticks
  2. The English language is just dripping in simile and metaphor (see what I did there)
  3. It’s good advice. A metaphor is assuming that your entire audience shares your level of knowledge and your set of opinions
Say you want to distinguish the capabilities of two teams. You might use a metaphor like medical specialists or sports positions. Is it truly going to land? Or are you just trying to find a way to soften a message that you’re afraid to say?

Sunday, February 16, 2020

Product Management Reading List


Inspired by Andy Nortrup’s thorough posting, I’ve dusted off my own recommended reading list. It doesn’t have reviews or feedback, just raw links. An interesting attribute of the times is that product management is recognized as an important function, but it’s not narrowly defined. That leaves a lot of latitude for recommending preparatory materials, and different lists have very different mental models of what a PM is going to do.

My approach to this has altered over the years as I’ve run more PM internships and mentored line PMs to avoid my mistakes and make their own. Specifically, I like to provide research pointers like this instead of prescriptive shortcuts; nothing kills the joy of discovery like forced march reading. While there’s a lot of interesting material here, it’s not all going to work for a given reader at the time they first see it. So poke around, find what works for you. If you’re coming from a STEM background, you may not need as much math and finance grounding as I have needed.

Product Manager Reading List

Specific to the discipline of product management

Marty Cagan, SVPG


Rob Fitzpatrick

Michael Mace


Ben Thompson, Stratechery


Eric Ries

Specific to leadership and teamwork

Kim Scott

Michael Lopp (Rands)


Passing knowledge of domains we influence and are influenced by

Thomas Freese


Seth Godin


Don Norman


Neal Stephenson


Alex Reinhart


Karen Berman


Dana Keller


Kieran Healy

Phil Simon

Sunday, January 26, 2020

Do I have a product here?


Sometimes I chat with people who are interested in starting a side business, or even leaving their $dayjob. That can be a really rewarding option if you’ve got the opportunity. Of course, there’s nothing wrong with not doing it! Some people simply don’t want to run a small business along with doing the value-adding work which brings in the money.

But if you’re willing to take on being your own boss, how should you evaluate if you’ve got a product that can float that business? Let’s work through a system for finding that answer.

Step one: Give yourself an hour per day over a week or two to do some research. You’ve got a blank sheet of paper and an idea, so let’s do some calculations and see if they can pencil out.

  • What would it cost to pursue the idea?  Do you need tools? material? People? Do you have to get certifications or build up a reputation before you can get those things? What does it cost in money and time to get to the point where you can start? What does it cost to continue operating once you start?
  • How much money must you make by what time to make it worth pursuing? Do you understand your budget? Have you considered what could be reduced and what is non-negotiable? Be honest here, if your minimum bar for quality of life requires excellent espresso every day, don’t budget for a can of Medaglia d’Oro.
  • Can you identify champions who will use your idea, gatekeepers who will allow it, buyers who will pay for it, and budget that exists today? This model is commonly used in business-to-business enterprise sales, but it’s not bad for considering any product transaction. Even if these roles are only different voices in a single consumer’s head, they will absolutely play out their functions. Consider your own purchase of a game: does your internal champion want the experience of playing it, does your internal gatekeeper approve (“what would my friends and family say”), and can you afford to buy it?


Step two: Assuming all of that pencil work comes out with a positive answer, you’re looking at refinements. Now it’s most interesting to consider: how much time will it take to prove or disprove that back-of-envelope estimate? Can you take a vacation from $dayjob and spend it on this idea? Hint: if that sounds terrible, you’re probably not going to like being your own boss. This part may be really tough because you’re going to need to validate your assumptions: talking to salespeople for quotes, talking to prospects, perhaps even asking your friends and relatives to invest. If you haven’t sold before, this is where you start learning, because if you can’t sell your idea to a friendly audience you’re certainly going to face some struggles with the outside world. In some software opportunities, it’s also necessary to ask: do you truly understand the technology that you intend to use? Do you need to spend part of this time learning to prototype your solution? Some people do very well in classes or seminars. Personally, I’d buy a stack of books and disconnect for a couple of weeks. Either is more weekends or PTO time from $dayjob.

Step three: If you’re now properly convinced you’ve got a product opportunity... how do you get from where you are now to where you want to be? How much money do you need to save? Are there trigger events or red flags you’re watching for? Now that you’re looking for the moment where you can commit to your new venture, you’re going to face additional stress from $dayjob, so keep an eye on mental and physical health.

Tuesday, January 14, 2020

Product Management Internships


An engineering internship program typically runs 6 to 12 weeks, often as a group exercise. Interns join scrums, 2-5 interns (generally 3), where there was a known deliverable on a topic of interest. They would experience the corporate version of their classes: understanding problems, sprinting to solutions, and presenting to the team on progress.

Problems to tackle will usually be areas needing investigation but not yet critical path for the business. Guidance comes from a team lead or senior individual contributor, who advises and runs a daily intern standup in addition to their team standup.

I’ve seen that program a few times. I don’t really like it... the projects can be poorly considered and don’t go anywhere, and the interns don’t end up understanding why the projects would or wouldn’t work in the real world. So it’s a lot like hackathons, only stretched over a summer instead of a week.

I’ve probably seen half a dozen force-directed graphs of data sets that could never scale at a real customer, along with a bunch of pointless dashboard re-skins. Not to mention solutions that could technically work but are not feasible in the company’s licensing model or data system.

What the interns do learn is process and culture fit. That’s not terrible, but a lot of it can frankly be taught in school instead. It’s totally wrong for product management. So how should our internships go instead?

Maybe this is regional, but in the SF Bay Area tech companies are competing for interns. You can win excellent candidates by showing why they’ll do real work which will ship. Intern wants to get a job. “Got to prove culture fit at $HouseholdBrand” is one path to that. “I shipped a feature at $Elsewhere and here it is” is another one. “Proved culture fit at $Elsewhere” is not so good.

Set that as table stakes and you’ve got a good base. Next, focus on how to teach product management. There are different philosophies for that, which I’ll touch on in another post.

Know everything, then automate!


The concept of virtual patching has set me off on a small rant.

If you’re not familiar, the concept is something like this: vulnerability scanners determine that PC42 in the CritStuff system has a nasty problem, but you can’t patch it for reasons. So instead, software magically figures out that exploiting this vulnerability requires access to port 80, and tells the nearest firewalls to drop anything headed to PC42’s port 80.

I’m down on two concepts here: the first is high risk automation. I have scars from network admission control. I’ve seen SEC filings delayed because of a properly quarantined laptop, never mind the attack ships on fire off the shoulder of Orion. Blindly implemented policy has high risk, and some knowledge of context is needed to make a proper risk-reward calculation. People aren’t perfect, but they’re better at this than software is.

The second concept I don’t trust is a requirement for pre-learning. Anything that requires the customer to learn in great detail how their systems work and what the dependencies are before they can safely act has put too much burden on the customer. Anyone remember host-based intrusion prevention systems? How about application virtualization? The environments that are simple enough to manage this way do not have sufficient resources attached to support a software vendor. Said differently, this approach has failed to find market traction enough times that it is now available as free open source.

One is supposed to argue that the virtual patching tool, like learning mode IPS before it, is able to save the customer the trouble of learning... except using those automatic tools just leads to learning about the dependency by accident instead, and therefore is still a market fail.

What about AI? What about it? A perfect robot would be more patient than a human but just as capable of learning the entire system, automating it, and maintaining the automation. But using that system would require the humans around it to either understand as well, or take a leap of faith. People will totally take that leap in order to gratify our laziness, but two or three failures will mean the system is rejected.  Can the robot be perfect? If not, can it be cheaper than a human? And is any of this conversation relevant to the far-from-perfect robots we can actually build today? Sometimes.