Network Ninja Quality Of Life: Enterprise vs. VAR

Like many of you, I’ve spent the last several years in an enterprise as the friendly neighborhood Network Ninja. And, like many of you, I became acutely aware of the downside to being the enterprise’s Network Ninja. I spent (way too) much time pondering if the grass was any greener on the other side before starting this year at a local Cisco partner. Since, despite my best efforts, I didn’t find many direct comparisons between the two sides of the industry, I thought I’d share what I’ve learned after some time on the other side.

Enterprise | Value-Added Reseller (VAR)

Scope

In the enterprise, scope doesn’t really come into play. The lucky Ninjas have a somewhat defined job role. Either they fix problems when they break, they implement new stuff, or they design/plan new stuff. The unlucky Ninjas do all of the above, every day. In any case, it can be hard to finish something, because there’s no beginning or end. After enough time it can become difficult to experience a sense of accomplishment because you’re never done. On the other hand, it can become clear to everyone how important a good Ninja can be. They seem to be involved in every problem. When there’s nowhere left to turn – ask the Ninja to do a capture!

VARs are on the opposite end of the scale, and it’s a big scale. Because money changes hands, neither a VAR nor their customer wants to be unclear about where a project starts or ends. I can explicitly count the number of projects I’ve successfully completed…and what each project entailed. Better yet, each project can be completely different than the previous one. Of course, this kind of scope can also feel limiting. When you reach the finish line, you’re done. I hope you’re happy with how that implementation went, because you can’t spend the next week tweaking it.

Learning

In the enterprise, the Ninja’s learning is heavily, sometimes entirely, dependent on the employer’s goals. If your employer just outsourced the SAN support 3 months before you arrived, you can forget about SAN training. Is your boss perfectly content with those 3500XL switches in the closet? There probably won’t be an OpenFlow or QFabric seminar in your future.  I’ve heard too many stories of employers that don’t bother sending Ninjas to training because it might lead them to quit. Consider yourself lucky if your boss understands that training is what keeps IT people happy.

I think this is the one area where VARs unequivocally win. In my first month alone I received excellent training on IronPort appliances and Cisco’s ONS platform. Throw in the information you can glean from your expert coworkers and every day becomes a class on packet pushing.

Cool Toys

This one is similar to learning, but latent knowledge is not the same as having a $500,000 pair of core switches in your data center that you can play with for the next several years. I expected VARs to win out in this category hands down, but the line isn’t so clear. At an enterprise you won’t be seeing new gear roll in every week, but you’re more likely to see equipment that costs big money. If your boss is serious about a 3-year hardware refresh cycle you might be going cold turkey for 24 months. But Christmas will come every three years.

VARs deal with a lot of small- and medium-sized companies, the kind that don’t need VSS/vPC magic or redundant data centers. You’ll get to play with a much larger variety of equipment, and you’ll probably get to work outside the traditional network silo. But the companies purchasing 20U chassis switches probably don’t need your help installing it – they’ve got their own guys.

After Hours Work

My previous employer grew quite a bit in recent years, so my team was fortunate enough to have built out most of the current network ourselves. If you gave me any source and destination address, I could easily tell you the make/model of each device your packets passed through. Most of the time I could give you the addresses of the interfaces involved. And sometimes I could tell you the color of the cable your packets were flowing through. There’s no doubt about it – having an absolute knowledge of your network is pretty awesome. But there’s a price involved, and it’s paid (almost) every time something breaks. How often were you called after 5pm last week? And how many times have you told your spouse “it’s almost over?” A Ninja can’t do everything, all the time.

But let’s not pretend after hours work only exists for enterprise employees. You simply can’t install a new pair of core switches during lunch on Tuesday, and every customer will have their own change control policy. At a VAR, you still have to work within those boundaries. Fortunately, partly because the scope is so well-defined, the cutover time can usually be negotiated well in advance. Working until midnight is a lot more manageable if you know it’s coming two weeks ahead of time. Support calls in the middle of the night won’t disappear either, but you might get to be part of a larger rotation. With an engineering staff of 14, I only have to carry the pager every 14th week. For me, that was huge.

If you’re curious about crossing the fence, I hope this will give you something to think about. For those that have seen the industry from both sides, have your experiences been similar? Am I right or wrong? What do you think?

Mark Ciecior
Mark is a network engineer, racquetball player, and CCIE #28274. Follow @mciecior on twitter to hear more about packets, racquets, and why he can't give up the original StarCraft.
  • http://twitter.com/bobmccouch Bob McCouch

    Great post. My experience has been the same as yours. I’ve actually worked all three corners of the triad – End-Customer Enterprise, Vendor, and VAR. I prefer life at a VAR by a wide margin. At an enterprise, I quickly got bored and lost motivation. I also got very experienced with the small range of products I was supporting, but had no touch on anything else.

    When I left the last enterprise I worked with, I went to a major telephony equipment manufacturer as an escalation field engineer. For me, that was complete Hell. Constant conference bridges with angry customers, non-stop on-call, and little control over the situation.

    Now I work for a small VAR dealing with a wide range of technologies and customer segments. Like you, new chassis core installs are rare for us, but they happen now and then (I’m working on a Nexus 7000 core project now, actually). But for me, the mix of technical sales, design, consultation, implementation, and support keeps things fresh. At a small VAR, you own a project from pre-sales through design, implementation, and on-going support. I like that, because if things go well I know it was because of my skill and experience, and if they go poorly I have no one to blame but myself (and I can actually choose to do better next time). That, combined with the need to always be “on” in front of a customer and project confidence, knowledge, and experience really keeps me engaged in the job.

    Your point about not getting to endlessly tweak things can be a bit of a drawback, as is going back into some gear or an whole datacenter you installed months ago for a follow-on and discovering it’s not been well maintained. But for me those also drive my desire to make sure I get things right the first time and to instill good practices and philosophy on my clients.

    I’m not sure if I’ll ever want to go back to one account.

    • http://twitter.com/mciecior Mark Ciecior

      In dealing with customers, do you do much in the way of training before handing over the final product?  I think the biggest way VARs can improve customer satisfaction is to make sure time is allocated after the cutover is complete to inform customers what actually happened, and how they can make small moves, adds, and changes.

      • http://twitter.com/bobmccouch Bob McCouch

        For us, it depends if the customer *wants* that or not. Some (mostly very small biz) are perfectly content to treat us like an MSP and ask us to do every little change. We don’t especially care to do that, but if they don’t have anyone inhouse then we kind of “have” to.

        However, my preference is to get the customer comfortable enough to do day-to-day admin on their own. We are interested in large projects, new design, campus/WAN deployment, etc. Our goal is not to have the customer call us (nor feel forced to call us) every time they need a new firewall rule or a new NAT build or need to add an AP to their WLAN. We want to be their “trusted advisor” who they call in to help them set and execute strategy, not the guys that have them locked into calling for every little MAC. I’ve seen some VARs not even give customers passwords to their own gear — that’s unprofessional paranoia in my opinion.

        Admittedly, though, if hours run long on the project the things that usually end up getting ignored or abbreviated are customer training and complete doc. But I had that in the Enterprise space too, where you get shoved onto the next project when there is still tuning or cleanup to do on the last one. I think that just indicates a need for better (or more pessimistic) project estimation.

  • @netmanchris

    HI Mark,

    Great post. I’ve also done all three of the holy packet herding trinity ( enterprise, VAR, manufacturer). They all have pros and cons. The one thing I always disliked about working at a VAr was the inability to ever do anything RIGHT. I mean that the customer was never willing to pay the price to actually fix something properly. they always wanted a cheap, quick fix.

    On the bright side, this meant that we, the VAR, we’re always getting called back in. But it just doesn’t feel good doi g half a job when you kow better. :p

    I don’t suppose that ever changes, but that was the biggest complaint for me.

  • Jawed Lashari

    Great post- I  worked for VAR for 5 years and joined enterprise last year. I totally agree  what you have  described here. 

  • http://twitter.com/christalsness christalsness

    I worked at a very small VAR prior to moving to the small enterprise that currently employees me.  At the VAR, I never got quality training nor time to thoroughly learn the products I was asked to implement.  The only education they were on board with was whatever free materials they could get from vendors, never training classes (cause those cost time and money).  They didn’t care if you learned anything, they just wanted you to pass the test so they could maintain their $PreciousMetal level partner ship with $Vendor.
    My current employer (enterprise) is much better about providing training.

    I also didn’t like how while working with the VAR I never felt like I got the chance to implement a project well, and didn’t have very good support from the senior engineers.  

    I know not all VARs are like this, but I think the smaller the VAR, the more like this they get.

    • http://twitter.com/bobmccouch Bob McCouch

      I know your experience is common, for sure, but it’s not necessarily size-related in my opinion. The company I work for is just the owner (a 10-year CCIE), his wife doing part-time books, and me. My experience is very different from yours.

      I think the distinction comes from whether the VAR is product or services oriented. If 80% of revenue comes from product and they’re just trying to push gear out the door, your concerns are definitely valid. They want to move gear, get it installed and signed off, and cut the cord as soon as possible. “They” don’t think you need to be highly trained just to get a base config on the thing and move on to the next project.

      On the other hand, if “consulting hours” is really the widget you’re selling (as we are) and selling hardware is just something you have to do sometimes as a means to that end (as it is for us), things are somewhat different. Since our installation, configuration, and consulting services are really what we sell (80-90% revenue most years), we need to get that stuff right and do an A+ job. Sure, we’re still bound by scope and labor estimates and sometimes things need to be curtailed because you’re just out of hours and the customer can’t authorize an overage, but barring that we’re driven to be very proficient and skilled at what we do because that *is* our business. If we do a poor job on config, or don’t know how to turn the knobs, or how to troubleshoot, we will lose that customer. It’s that simple.

      Unfortunately it sounds like you just worked for a company that wasn’t interested in having its engineers do good work, but rather just turn product over.