Tag Archives: LEARNING

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 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

BOOKS

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
    or
  • “I want to ask about something that seems really basic but I don’t understand”
    or
  • “I want to ask about something that I think everyone else in the room already knows
    or
  • “I want to ask about something that seems to be accepted but I don’t believe.”
    or
  • “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
Roadmap
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.

SMASH.

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.

Three meetings that didn’t suck

“If you had to identify, in one word, the reason why the human race has not achieved, and never will achieve, its full potential, that word would be ‘meetings.’  (Dave Barry)”

One of the things I’ve noticed as I’ve adjusted to life here at Infinio is that we have different types of meetings than I am used to from being at a big company.

First off, we have a lot more ad-hoc meetings.  Perhaps due to the open floor plan, it’s far more common to mosey over to someone’s desk and start chatting rather than to schedule time with someone.  “Can I grab you for a sec?” “Are you interruptible?” are very common here.

Twice a week I participate in a marketing “stand up” meeting.  I remember reading about these in grad school as part of Agile/Scrum methodology, although not really related to marketing.  In ours, we go “around the horn” and everyone does a quick update of their major goals for the day.  Sometimes we have a short conversation about something or show a piece of work off, but usually it’s just to set up for the day.  Oh, and it’s called a “stand up” meeting because we literally “stand up.”  That keeps it nice and short.

Last Friday I went to my first engineering iteration meeting.  I am such a dork – I was really (*really*) excited to attend.  Engineering at my last job was not a resource directly accessible to me so it was exciting to see what happens in one of their meetings.  Basically, the engineers took turns talking about their work on particular features or problems, with at least 6-8 of them talking in a 2 hour meeting.  People asked questions and expressed worries, and there was a lot of sharing of images and screen shots.  We used Google Hangouts to connect to remote engineers so the graphics were definitely important.

I learned a few specific things at the meeting.

1.  Despite being warned that I might be bored I was pretty well-equipped to follow most of what was going on in the meeting.  With the exception of some coding buzzwords, the bulk of the things I didn’t understand had more to do with my gaps in knowledge around VMware than anything else.

2. The relationship between engineering and QA is fascinating – like siblings maybe?  Everyone wants to release a great working product but it’s QA’s job to poke holes in the code before it ships.  (Nudge, nudge, poke, poke, I’m not touching you….)  The groups were friendly and respectful towards each other.

3. Regarding language – I was impressed by how many times “the customer” was referenced (17) and how actively they seemed to be a silent participant in the meeting.  Specific customers were also mentioned and resolving their issues was clearly top priority. There was also some reference to “technical risk” and “technical debt” which were new concepts to me.

4. Finally, I understood – immediately, in a flash – what automation testing is and why it’s so important.  Suddenly, too, I understood what “DevOps” meant.   And I’m not sure either of those things would have made any sense if I hadn’t attended that meeting.

The other new kind of meeting I have begun attending since joining Infinio is the weekly all-company meeting.  After our company lunch on Wednesdays, our execs all get up and talk about what’s going on in their domains – Engineering, Sales, Marketing, and our CEO.  They share good news and bad news and major strategic decision-making.

It was really fascinating to see the engineerings ask about marketing programs and plans – it reminded me that you can’t just wake up one morning and decide to do marketing well any more than you can wake up and decide to do engineering well.  I forget that sometimes – even my own biases work against the field I’ve chosen to work in.  The other cool thing about the all-company meeting is what happens afterwards – people walk over to each other and follow up on things they heard.  It’s another good way to get engineering, sales, and marketing talking.  A test engineer came over to me to comment on some market research I was doing because he had worked at one of the companies whose technology I was researching.  Score!

I like meetings that don’t suck.  I hope to attend more of them.

CREATE TABLESPACE Blog

I’m glad you found yourself here.

You may know me (and some of this) from Twitter, but to level-set: At the end of January, I left my job in solutions marketing at Dell after 7 years.

kendallAfter a short hiatus, I joined Infinio Systems – a software startup in Kendall Square – as Director of Product Marketing.  There is so much to digest and learn, and there’s no way to share the experience in 140 character chunks.  So here I am in the blogosphere.

So why name my blog “storageDiva’s Tablespace”?  Two reasons:

A tablespace is the abstraction layer in a database that sits between the logic of the database and the physical datafiles it contains.  Basically, you group several tables and indices together and while they are physically stored in datafiles, the collection of them (regardless of physical location) is a tablespace.

I like the metaphor of this blog being a tablespace of interrelated tables, because I plan to share all sorts of interrelated ideas about my experiences in technology, marketing, and life at a startup.  Here’s a swag at what I think the “tables” would be called: 

  • LEARNING: My education around caching, performance, and all things Infinio
  • CUSTOMERS: What I learn from our customers and our not-customers
  • TECH: Thoughts and ideas about our product and the industry at large
  • MARKETING: How product marketing is changing in the Internet/Social Era
  • STARTUP: Life at a startup, especially after coming from a big company
  • XX: What it’s like to be a woman working in technology
  • HOME: Balancing my work life with my daughter(“babyDiva”) and spouse (“mrDiva”, also at a startup)

I said there were two reasons for the blog being called “storageDiva’s Tablespace.”  The second reason comes from Sheryl Sandberg.  In her book and TED talk she relates a story of being at a meeting and notices that the young women are sitting on the periphery of the room while the men all sit at the table.  She urges the women (and the reader/watcher) to claim a seat at the table (not behind it) to ensure their voice is heard.

The phrase “table space” is a reminder to myself that I have gotten where I am by always claiming my space at the table, long before the other Sheryl made it trendy.

I hope you’ll stick around.