Monthly Archives: April 2014

Spelunking to uncertainty

Last week I wrote about the major differences between my experience at Dell and my experience here at Infinio.

One of those was the idea that here, there’s no supposition that at least someone, somewhere knows the answer.

That is really, really hard to digest for someone like me.  I have a predisposition to assume that there is an answer to everything.

I shouldn’t think that, I know.  Even my professional training as a mathematician should teach me that isn’t the case – look at how many unsolved problems still exist in math and may forever.  Look at Godel’s incompleteness Theorem.

Or, last week I was at an engineering meeting and the topic of discussion was a terrible little behavior we were seeing in our product’s interaction with another product.  This behavior came up over and over, and while we fixed each instance of the problem, we had no way of knowing that we had addressed every instance of the problem that could arise.

While extensive testing could minimize that risk, it can’t eliminate it entirely.  As one of the engineers said, “There’s no real way to know when software is ‘done’ or ‘right.’”

This feeling has awed me in the past once before as well.  Before babyDiva, mrDiva and I used to travel a lot, and one of our best vacations was to Belize.  We had planned to hike ATM, a well known cave-system in the Cayo district, but the rains had been so intense that it was un-navigable.

Disappointed, we went to our hosts who said, “Oh, let’s call Ken!  You can go see Ken’s cave.”


mrDiva, our guide Leo, and Ken, with Ken's 1979 Land Rover

mrDiva, our guide Leo, & Ken, with his 1979 Land Rover

Ken’s cave, it turned out, was amazing.  Known more formally as Achtun Chapat, it was only accessible by a bumpy ride in the back of Ken’s 197X Land Rover.  He and his guide led us through a 5-6 hour hike into the cave system, pointing out bats, bones, and pottery shards as we went.  There were cathedral height ceilings and crawl spaces.  Beautiful stalactites and stalagmites.  It was pitch black when we turned off our headlamps.  Like, literally black.  At the end of the cave, we sat under a sinkhole that provided some sunlight from above and enjoyed Ken’s wife’s homemade burritos.

As we were sitting, Ken mentioned casually that this was one path, but they hadn’t mapped the entire cave yet.  There were probably 100’s of additional yards of cave that nobody had yet traversed, because of safety issues – low oxygen rates and unpredictable lakes.

It was inconceivable to me.  This cave was obviously a national treasure for Belize, at least as complex and rich in archeological and natural items many of the well-known sites in Central America.  How could they not have mapped it out?  Aren’t there X-rays or robots or something that could do this?

mrDiva and me at the entrance to Achtun Chapat

mrDiva and me, at the entrance to Achtun Chapat

But there aren’t.  Or they’re not economically or practically viable in Belize.  Or Belize chooses not to explore this for fear of losing control of their resources.

Whatever the reason, I am still overwhelmed by the idea that there’s a cave that I have been in that is only sort of understood.

Sometimes, we just don’t know the answer.


3 things that have changed at work

After my very early impressions of Infinio, I’ve tried not to overthink the transition.  I’ve had moments of reflection here and there, but being prone to over-analysis I’ve tried to be “in the moment” here.

Recently, however, a handful of themes have continually appeared in my everyday work that I want to share.  My life at Dell was *so* different from my life here.

In my decision to come to Infinio, one of the most important conversations I had was with Matt Brender, who had recently made a similar transition from EMC.  In fact, when I interviewed at Infinio, my now-manager Carrie quoted to me from his blog:

At EMC you first assume there is a process.

At Infinio, you start confident there isn’t one yet.

Here’s his entire post on his transition to Infinio.

Anyway, back to ME.  Here’s what was different when I was at Dell:

1.  I (mostly) stuck to my quarterly plan.

At Dell, I’d propose a 3-month content plan for my team, negotiate with them on it, negotiate with my management on it, and usually by week 2 or 3 of the quarter, we’d have agreement.  I was measured on (and great at) how well I delivered that which I committed to.  Sure, we kept some slack in the plan for unexpected projects, but that was the exception, not the rule.

In fact, if anything major came up, more than a few days of work, we’d go to the work plan and decide what was getting pushed to the next quarter.  We’d let the stakeholders for the different projects fight it out about whose we tackled.

This is not to say that we didn’t work hard and try to overdeliver on our plan. We often would work late to meet a deadline or otherwise do things that otherwise seemed impossible.

But there was a language and a process around how we handled additional workload throughout the quarter, and in fact navigating that is one of the major skills managers at Dell acquire and use.

Is that different at Infinio!!

We did create a quarterly marketing/content plan this quarter, and I’m told it’s the first time we’ve done it at this level of detail.  However, two weeks later, I’m looking at my plan nostalgically as I would a homework assignment list of mine from high school.

It’s not that I don’t need to do those things, but in the span of just a few weeks, so much changes with respect to prioritization and opportunities that it seems outdated very quickly.

And as new things come up, there’s no negotiation on what doesn’t get done.  It’s more like triage – “well, I’ll have to delay creating that training module so I can get us certified before this show we just decided to do,” but that doesn’t mean delaying until I next get to write a quarterly plan, it just means something jumps the queue.  All the work still has to get done.


2. I didn’t do a lot of guessing.  

For example, when we launched a new product, we knew what resources we needed to support it. Sure, we may not always have known exactly what claims would resonate best with customers (or what results we could achieve in the lab) but we knew we needed claims and there was a process to get them.  We often felt understaffed and under-resourced, but the reality was that we had teams of people dedicated to various different aspects of the marketing for a launch, a refresh, and sustaining operations.

There was no concept of someone at Dell not knowing the answer.  That person may not have been in the meeting or in the room, but you could ask and someone would have an opinion which was determined to be “The Answer.”  The job of being a manager at Dell was very much about executing within the system, escalating uncertainty, and decision-making within a pre-defined structure.

At Infinio, I think the phrase I hear most often is, “I’m not sure, let’s try it.”  Everyone from our executive team on down talks about A/B tests, experiments, learning, and mistakes, nearly every day.

This isn’t to minimize the experience of the leadership team here or the employees – it’s an amazing group of people from Endeca, vKernel, EqualLogic, NetApp, and other name brands.  Many of them have built a company before.

But we are in a new market selling something that is very disruptive – and there’s no codified “right way” to do that.  Inbound marketing is still an adolescent.

We just don’t know the answer sometimes.

Back to the discussion on priorities, often during my weekly meeting with Carrie, I’ll bring a list of the new tasks I’ve accrued during the week.  We’ll look at it along with my plan.  “Should I do the content for this project or create the materials for this project,” I’ll ask.  And we’ll consider both, without knowing the “right” answer.


3. At Dell, I was detached from the minutiae

At Dell, I was light years away from lots of daily decisions.  If I staffed a tradeshow, I basically just showed up with the right polo shirt on.  For Dell Storage Forum, I was a little more involved in things like T-shirt slogans and activities, but mostly I just knew about them early, I didn’t create them.

In contrast, the number of details that come across my desk as part of a 5-person marketing team is incredibly high.  What should the booth graphics look like for Citrix Synergy?  What should our giveaway be?  Is this close enough to our “blue”?  Is the text in this ad centered right?  With which vendors should we split our lead gen spend?  With whom do we syndicate which content?

It’s an amazing education.

All of it is an amazing education.

(It’s also exhausting!)


I moved to Boston because after college everyone I knew was either going to Boston or to New York, and I figured, “hey, I already know New York, let me try Boston.”  I’ve never left.

CT1 Bus, April 22, 2013

CT1 Bus, April 22, 2013

Perhaps there’s something special about any city but when I’m at Fenway and the first few notes of “Tessie” start playing after a win I get chills.  There’s the cash-only red sauce Italian restaurant we wait hours for a seat at, the food trucks that gather at the Sunday market, the parks that our dogs have taken over quasi-illegally, the 5Ks and 10Ks that occur around the city, the Pride Parade, the walk around Jamaica Pond, the first Sullivan’s grilled cheese of the season at Castle Island, the friends you seek out because it’s 4th of July and they have a roof deck – maybe everyone feels this way about their city.  But it feels special.

Now that I commute by bus and train (and/or walking) rather than by car, I feel even more connected to the city.  I knew that my new job would be easier on me and on my family because it was a shorter commute, but I didn’t know that it would change how I felt about Boston.

Commuting this way, I’ve run into neighbors and friends serendipitously, I’ve heard Sinatra standards in Spanish in T stations, I’ve learned about events in the city from ads on the bus, and I’ve seen things in shop windows I’d never otherwise pass by.  I’ve walked by the Make Way for Ducklings statues in different garb, I’ve watched the progress on the Longfellow Bridge project (note: not much), and I’ve walked by the Back Bay fire memorial at Ladder 15/Engine 33 house.

Sculpture in a shop window

Sculpture in a shop window


Guy in Park Street Station playing an instrument I had never seen

Guy in Park Street Station playing an instrument I had never seen


Memorial to firefighters from Back Bay fire

Memorial to firefighters from Back Bay fire

Sure, Bostonians can be harsh and rude, but I’ve seen people give up seats for pregnant women, hold doors longer than necessary, hold a bus someone was running for, and return a carelessly dropped monthly T pass to a certain curly-haired product marketer on the second day of the month.

And on no day of the year does Boston feel better than it does today, Marathon Monday.  In the years before the bombing tragedy, it was hands-down many people’s favorite day of the year.  A holiday just when the weather was starting to get nicer, celebrating…umm…a day Sox game and the marathon?  Not sure we really know what “Patriots” are being recognized today but we sure do love it.  And it’s almost the degree to which Boston loves this day that made our recovery from the marathon attack so strong.  As David Ortiz so eloquently put it, “This is our f*ing city.”

This weekend, the weather broke into beautiful, and Boston was teeming with visitors – many of them running the marathon.  At the supermarket yesterday there were dozens of runners milling around with bananas and coconut water and vying for the last few bottles of Gatorade.  Each year, I look forward to seeing the unique marathon colors in the form of the warmup jackets people get when they register throughout the weekend.   This year, it was a mix of the new blue and orange with many people still sporting last year’s colors.

This morning on the T there were runners headed to the busses out to Hopkinton.  The Marriott whose lobby I cut through had water, granola bars, and bananas out for the runners, and the driveway was full of people packing up cars and getting ready to run or to root.  The Starbucks staff were all in “Boston Strong” T-shirts.

I’m sure there will be days this winter when I am splashed by a bus a la Carrie in Sex and the CIty, when my train is delayed, and when I am slogging the 10 minutes from the T station to my office.  I’ll look back at this blog post and wonder if I couldn’t be this happy in, say, San Diego.  Or Jacksonville.

But I know I couldn’t.

Boston, you’re my home.

The myth of the greenfield opportunity

Attribution: walknboston/FLICKRIt’s baseball season here in Boston – home of the WORLD CHAMPION RED SOX – and Fenway couldn’t look more beautiful. The lights shine, the uniforms are crisp, and the field is a bright, grassy green.

A green field.

Greenfield – also what we in sales and marketing call a completely fresh opportunity – in contrast to “Brownfield” which is an opportunity in an existing environment.

For example – say a customer is deploying a new CRM application into their environment; that is a greenfield opportunity.  If a customer has a CRM application that needs an upgrade, that is a brownfield opportunity.

Wikipedia: “In many disciplines a greenfield is a project that lacks any constraints imposed by prior work. The analogy is to that of construction on greenfield land where there is no need to work within the constrains of existing buildings or infrastructure.”

But in reality, do greenfield IT infrastructure opportunities really exist?

Probably not.

First off, each person involved in the project brings with them constraints from prior work:

  • “I had a bad experience with Vendor X and I’ll never deploy anything mission-critical on them again”
  • “I took a three-week training course on Product Y so we should use them.”
  • “My brother-in-law works for Vendor Z so we should have them in.”

More importantly, as organizations are being tasked with “doing more with less” it’s very rare that any project is going to be deployed on completely new hardware.  More likely, IT departments are being asked:

  • “Don’t you have a VMware farm you can just add this application to?”
  • “Can’t you support a few more users on the existing infrastructure?”
  • “What can we do with some of that hardware you have lying around?”
  • “We already have an investment in Product A and Product B, can’t we use that for this?”
  • “Should we be looking at the cloud for this?”

And pilots and POCs, formerly the opportunity that IT had to try out new hardware to evaluate their applicability to a new project, are often shafted when it comes to hardware.  “It’s just a POC, you can use anything for that” and “Let’s pilot it on the old hardware, we can figure out what we’re really going to use once we deploy for real.”

In short, rare is the IT organization who is building a new datacenter from scratch, deploying a new application on brand new hardware, or unencumbered with legacy investments.

How should this change our sales and marketing?

First, we should always talk to customers about what they currently have and what their plans are to continue using it.  This is not to say that if we have a disruptive technology that we shouldn’t introduce it to displace an incumbent – of course we should.  But knowing the lay of the land with respect to incumbency is necessary to become an extension of the customer’s team.

Next, we should be introducing solutions that enhance a customer’s existing investment.  (Easy for me to say, I work at Infinio, where our solution enables customers to get more performance from their existing storage systems.)  Again, disruption isn’t bad, it’s what make the world move forward.  But it’s not always a revolution, we’ve turned into pretty intelligent beings based on evolution.

Finally, we need to put some meat behind the “do more with less” marketing slogans.  “Do more with less” can’t mean “Buy into my expensive product/architecture and your applications will run better.”  We need to provide proof points and examples of other customers who have leveraged solutions to actually spend less money or get more out of existing infrastructure.

I stole this reading list

In January 2013, I had babyDiva. While on maternity leave, I joined a Moms’ group, and as it turned out, one of my closest friends from that group is also a high-tech marketer.

On Facebook, she asked “Friends in tech: In the past year or so, what’s best product/marketing/start-up book you’ve read or blog you’ve been reading?”

Here are the responses, organized (sort of), with a few more of my favorites included. A few of these are mobile-specific or marketing-specific, but it’s a good selection:

Corporate blogs:
Buffer Blog
Buffer Open Blog
Hubspot Blog
Salesforce’s Blog
Moz Blog
Marketo Blog
Eloqua Blog
RaizLabs blog and podcast

Personal experience blogs:

News aggregators:
Hacker News
reddit Entrepreneur
Growth Hackers


Got any other favorites?  Comment on this post and let me know!  Boldly missing are female personal experience blogs and more technical stuff, but I’m interested in anything else that will teach me something.

3 dumb questions I asked last week

Every day for the first 12 years of my education, my father sent me off to school with a single piece of advice: “Ask good questions.”  Question by Tim O'Brien

He has a few other standards (doesn’t everyone’s dad?), but this one has always stuck with me.  I think it’s a major contributing reason as to how I ended up in technology.

Right now I’m in the phase of learning where the good questions are dumb questions.  Because when we say, “I have a dumb question” what are we really saying?:


  • “I want to ask about something that I think that you think that I should already know
  • “I want to ask about something that seems really basic but I don’t understand”
  • “I want to ask about something that I think everyone else in the room already knows
  • “I want to ask about something that seems to be accepted but I don’t believe.”
  • “I want to ask about something that you didn’t explain very well.”


I love asking dumb questions.  Because they usually aren’t that dumb.  And right now they are the key to my building a strong foundation of knowledge and capability.

So I think they are good questions.  Here are some of the ones I’ve asked recently:


1.   Why is our product called a “content-based cache?”  Aren’t all caches caching content?  

Well, yeah.  Usually.  But when we say ”content-based cache,” it is in contrast to “location-based cache.”

  • Location-based cache says “oh, you asked for the data in slot 7 already.  I have that slot 7 data, here it is.”

  • Content-based cache says “oh, you asked for the data whose hash is xyzabc.  I have the data whose hash is xyzabc, here it is.”

The benefit of using a content-based caching scheme is that if the same data is in two places, it only has to be stored in the cache once.  That makes the cache’s logical size larger.

2.   So is write-through cache write cache or not?

Write caching comes in a few flavors.  Write-back cache might be what you think of when you think of write caching.  When writes come in, they are written to cache immediately.  At some point, they get moved to more permanent storage (or not.)

Write-through cache is what Infinio does.  It doesn’t mean that we aren’t caching writes – in fact, every write that comes in is added to the cache.  However, the original write is also committed to the storage system immediately.  This “warms” the cache by putting the most recently written data into it.  However, unlike write-back cache, there’s no point in time in which the data is only in cache and not also on disk.

Write-through cache is not as fast as write-back cache, because the data is being written all the way to disk, not just to local (faster) cache.  But it is less risky because all writes are going through to disk.  For our solution, it also means you don’t have to make any changes to your storage system because snapshots, replication, etc., all work exactly the same way as before Infinio.

3.   What’s all this discussion about Offload vs. Acceleration?

My first day, I sat in on a meeting where for 30 minutes we discussed whether we do offload or acceleration.  I say “we” but I had no idea what was going on.  There were metaphors involving cars and engines that were not helping me understand anything any better.  I asked someone to explain it but it felt like all they were doing was describing the product again.

As it turns out, here’s what they were talking about:

The core function of our product is to offload read requests from the storage system by serving them from our cache.  There are a lot of benefits that come out of this offload:

  1. Some reads are much, much faster if you are requesting data that is in your local piece of the distributed cache.

  2. Some reads are much faster if you are requesting data that is anywhere in the distributed cache.

  3. Because fewer requests are going to the storage system, the requests that are can be served more quickly because the storage system is less busy.

Technically, the first two are acceleration and the #3 is offload.  You’re welcome – now you don’t have to go to a meeting about this.

I feel pretty confident that this “dumb question” phase is far from over.  I’ll share my next few shortly.

The part about being new you can’t speed up

Clock by Jef Fisher“Hit the ground running”

“Get up to speed quickly”

“Drinking from the firehose”



However you talk about it, I definitely felt a lot of pressure when I started this job to contribute as soon as I could.  I read The First 90 Days, which suggested creating a learning plan.

“Great!”  I thought, “I love plans!”  I wrote down all sorts of things I knew I didn’t know, and that I knew I didn’t know where to go for, and some notes on how I’d get up to speed.  It looked something like this:

Server-side caching
VMware networking
VMware storage – set up lab myself?
Startup competitors – Pernix, [[unintelligible from interview notes]]
EMC/NetApp flash products
Product architecture – hashing, pointers, table?
Product GUI/demo – performance metrics we do/don’t use
Product management team meeting
How to get collateral produced
Website changes
Engineers – how to interact?
Engineering – agile?
Product documentation

OK, it wasn’t really a plan.  But it was a starting point.

And it started out well.  I can tell you all about a distributed, deduplicated, server-side cache.  I know what makes storage content-addressable, and why content-based cache is called content-based when all cache caches content ;).  I met all my (great!) colleagues, learned how I’d do things, and got started writing some internal content.


Did you hear that?  That was the sound of my hitting a wall.  I tried to go faster than the speed of time.  Let me explain.

The first time it happened was 10 days in.  The Director of Product Management had set up a recurring 1×1 for us, and I came prepared with a bunch of questions about the technology, product, and market.  At the end, I asked if I could answer anything for him.  “Have you noticed anything not currently on the roadmap that the product is missing?” he asked.

Here it was – my dream moment professionally: someone asking me to influence a product! and I. Had. No. Idea.  I had no intuition.  I hadn’t had enough time to think about it.

It happened again the following week; I was on Lauren Malhoit’s podcast and she asked about write caching.  I know that our product does write-through caching, I know how it works, and I know the pros and cons of it.  But I got totally tongue-tied and twisted when she asked.  Because I hadn’t had time to practice explaining it.

A former customer of mine came in for a visit to say hi and check out our technology.  That was a little better – I got to practice explaining the technology to someone who already knew me and got to do it in front of our stellar SE’s, so they picked up where I petered out.

But right now in one of the other tabs I have open in Chrome is our “messaging document.”  And I’m a little stuck on it, because I haven’t had the time to develop the intuition on how to talk about our technology yet.

It’s *really* frustrating!  I don’t know any shortcuts to internalizing concepts so they feel like my own.  I don’t know how to get my intuition to “click on” sooner.

There’s practice – sure – repetition is better than no repetition.  But you can’t flash-cook a brisket.  No amount of repetition can replace giving yourself more time.

And it’s not the kind of time that you can make at night or on the weekends.  It’s the kind of time that happens…over time.

Time for ideas to percolate.

Time for relationships to build.

Time for opinions to form.  

It’s the number of walks to and from the T station where you reflect on the day; the number of “aha” moments in the shower, the number of conversations that you overhear and people who stop by your desk and chat.

You just can’t make that stuff go any faster.