1 easy trick to scaling your business as a Solution Provider

simplifying-design-documents-systems-engineer

You’re a business owner, head of Sales, the leader of a Systems Engineering (SE) division, or maybe a Systems Engineer yourself, and no matter what you do the team always seems to be too busy with billable work to deliver great documentation to your customers. The first part of the sentence, that you’re all too busy, is a great problem to have – keep rolling in that revenue! The last part, however, is a death sentence. Whether it’s a scoping document, Statement of Work, design guide, implementation plan, or even a Bill of Materials I’ve seen too many SEs and too many SE teams burned out by, and several value added resellers (VARs) get crushed because of, poor customer documentation or worse – none at all.

Whether we’re talking about a rough scope for a bid, technical bits of a Sales proposal or just part of the final implementation sign-off, delivering documentation to your customer is a big differentiator. Give them low-quality documents ,or no docs at all, and you risk spending hours or more of non-billable time – because if they have any wits about them they’ll argue it’s your problem for never documenting your work – on a reassessment of their environment\systems\configurations in the future. Not to mention the impact this tends to have on customer relationships. Providing your customers with high-quality deliverables, on the other hand, might at first sound like you’re giving away the keys to the kingdom. What you’re really doing is showing that you’re in this together, you’re working from a place of mutual trust, and they can count on you to provide absolute top-notch effort.

Generating high-quality documentation can seem like a daunting task at first but the value is almost immeasurable. The real “1 easy trick” is to change your frame of mind about it. Instead of viewing documentation as an afterthought at best, or a “crap waste of time” at worst, you need to truly believe in the power of documentation. Understand that documentation can and should be created first in any project. And then act that way.

The “1 easy trick” really is that easy, so I’ll say it another way: stop trying to jam documentation work in at the end of your projects and start launching your projects from documentation. I’ll share a real example from my past that highlights the power of documentation as a proactive tool. Names have been changed to maintain customer confidentiality.

The power of documentation

A customer opportunity came up at ACME Corporation to provide both a physical office migration and an email server migration from an on-premises solution to Microsoft Office 365. Several area IT solution provider Sales teams had approached ACME with very simple proposals, none more than a few pages long. Just enough to “show up and throw up” at the 2nd or 3rd meeting and talk about “how standard and easy these types of jobs are, no sweat, when do you want to get started?” Whether any of those Sales teams did everything else right or not, none had won the trust of Bob, ACME’s VP of IT, because, and I quote, “nobody has taken the time to actually show me how the project will be executed. So forgive me, I appreciate the meal, but I hope you guys aren’t just going to show me a stock proposal and a quote as soon as we’ve finished eating.”

It was at a Friday lunch meeting with Bob that he said this. I looked over to my sales counterpart Jim and I shot him my “I’ve got this” look. He changed whatever he was going to say to, “Sean, you ran IT for a similar-size shop a few years back. What would make you comfortable if you had the same project fall in your lap?”

“Bob, like Jim said I’ve been in your seat in a past life. Maybe I’m reading into things too much, but I’ve made the mistake of trusting a solution provider too much, too, and so I think I understand where your concern comes from. If I come back to you Monday morning with a detailed plan for each of these moves, and – assuming you remember our rates – can Jim follow-up with you in the afternoon to talk about sign-off and a start date?”

Long story short, I worked with my manager to shift my last meeting for the day off to another engineer not so I could head home early on a Friday, but so I could document exactly how I intended to execute both the physical migration and the email system migration, from the high-level all the way down to the individual device and user. I showed up at the ACME offices on Monday morning, asked Bob for 15 minutes of his time to review the plans with me, and called Jim on my way back to the office to let him know Bob was ready to deal.

How did we scale to that point?

The answer is a simple one and has two parts. First, a predecessor had shifted the company’s approach to project management the point that every time Sales went to close a deal they started the close with a documentation plan. All of the engineers, myself included, were trained to understand that if a rep said they were planning to close a deal tomorrow it meant “get started on the ‘detailed design document’ and don’t sleep until it’s finished because we need it for tomorrow’s meeting”. Second, we didn’t believe in “light” or “high-level” templates, even for proposals, and the business invested the time in creating extraordinarily detailed templates. Every proposal started as a 20+ page form in Microsoft Word with an executive summary, space for several diagrams of the current state and the future state, and then a plethora of numbered lists, bullet lists, form fields, and tables where we would fill in the specific plan, in exacting detail, of how we would go from “current” to “future”. In this case I’d used our “data center move” template and our “email migration” template. I had to make many assumptions while filling out both documents, but assumptions can be changed as simply as “Find and Replace” in Word and other tools.

Not having a plan at all, however, would have lumped us in with everybody else.

The best part? Doing all of this work up front not only meant much greater chance of success in our Sales team, but also that much less work for me! Why? Because I had laid out all of the steps ahead of time, all I had to do on the day of the migrations was show up and go through my checklist! Many times, the person drawing up the design wouldn’t be the person executing the work, and we used this as a constant test of our planning capabilities. The company believed in the power of documentation so much that we all bet our reputations on it. This level of documentation was also useful when navigating those challenging situations where something wasn’t working right and we had an irate customer on our hands. Any Support Analyst would start by stepping through the docs to validate whether the configuration had changed since the last time any of us did any work, and then either get the OK from the customer to revert the change or to adjust other parts, of whatever system they were dealing with, in order to get things running. And talk about continuity in our approach: if they did make a change, they would first document a rollback plan, again using a template, make the change, and then update the design with the new configuration before closing the ticket. If anything bad happened in the future, we were again covered, as any other Engineer or Analyst could step through the docs and see step-by-step what the correct configuration was supposed to be.

For more information on scaling your documentation capabilities from “average” to “amazing”, start with the references below. You’ll need to get comfortable with creating templates, forms, macros, and other tools available in Microsoft Office and other productivity suites. Whatever tools and techniques you ultimately land on, if you’re looking to scale your capabilities as an individual contributor or drive scale across your team, creating solid documentation up front and believing in the power of documentation is critical to your success.

 

http://www.makeuseof.com/tag/integrate-excel-data-word-document/

 

Improving your presentation skills

presentation

Whether you’re working through a fix with a customer as a support analyst, negotiating for greater budget as a technology leader, or proposing a technical solution to a business problem as an IT solution vendor, you are presenting. Your goal in any presentation is to build genuine trust with your audience and then leverage that trust toward mutually-successful outcomes. You fix the problem and have a happy customer leave you a 10 out of 10 on a feedback form. You sell your product and turn your customer into a champion who goes on to refer many of their contacts to your company.

One of the most effective ways to build trust is to speak from the place your audience speaks from instead of from your own.

One way to speak from the place your audience speaks from is to understand their language and make it your own. The benefits of speaking a shared language are researched and well-documented far better than I can do here. Instead, I offer some simple tips that I follow to drive maximum value:

  • Learn about your audience. In Support this can mean looking at the customer’s information in your company’s database. In Sales you may reference LinkedIn and other tools. In Marketing consider building an understanding of your different ideal customers, also known as creating “personas”.
  • Keep your words simple. Simple words are often the most successful.
  • Avoid expressions, idioms, other “local” language, but adapt to your audience where possible.
  • When you must use jargon, start from your audience’s language.
  • Challenge your audience to share in your language as you share in theirs.

A practical example where we can combine the last two points to greater effect is to use your audience’s language on one slide and immediately follow that with a slide that only contains your own relevant jargon. This leverages your audience’s perspective to guide them to your own. In this way you can successfully move to a shared language.

Edit, edit, edit. Whether you are writing, presenting from slides or a whiteboard, or speaking on the fly, you can edit. Sometimes you’ll only be able to edit forward, for example in tech support you may not speak with that same customer again but you can edit forward by reflecting on that conversation in order to identify improvements for your next conversation with the next customer.

If you feel weak at editing, consider engaging with people and brands on Twitter, where you are locked to 140 characters. I’ve got 20 years of creating and presenting business and technical content for internal and external audiences. 6 to 12 months of engagement on Twitter were all that was needed to change not just my language but the reception of my writing and my speaking. Enforced brevity is a powerful educational tool!

Climbing the mountain

When I joined Zerto back in 2012 I knew I was in for an adventure. At the time I was hired the company had less than 50 employees worldwide, a few dozen reseller-partners, a handful of Cloud Providers offering Zerto-as-a-Service, and a 2.0 product which usually took a couple of hours of hands-on work to get up and running. I had seen Zerto in a lab but never in real production use. The company had about 100 customers with what felt like good product/market fit, a recent Series-B, and who I felt (and still do) was the right team for the job.

The next two weeks are a blur of me sitting in the cube of the other Sales Engineer at the time, learning the Zerto software and creating process (read: making it up as I went) out of what is better known as typical startup chaos. Case in point: due to a massive workload and a need to get going ASAP I downloaded all of the documentation on Zerto to an iPad that I took with me everywhere. The morning train commute, the bathroom, when I say “everywhere” I mean “everywhere”! 10 days later I was leading my first technical calls.

Coming from a reseller that I thought was the epitome of “high activity”, I have to admit that I was floored. Potential customers and partners were exploding with interest. I’d hop on a plane with one of my sales reps, hit 7 meetings a day through a half-dozen states in a week, and fly home for a weekend of rest and working in my lab. Come Monday I’d have ten conference calls a day through 8 or 9pm that Friday. Rinse and repeat. Late in the evening on December 31st, 2012, with the last order in the system for processing, the reports showed that it all paid off: we all saw that we had brought on over 250 customers through the year, or at least one new customer every day since I started.

Now fast-forward several years.

We recently held an Americas business review. These are standard in sales and different companies hold them at different frequencies through the year. A sales manager asked a question regarding one of our key performance indicators, or, “How many meetings should we hold our folks accountable to each week?” A few opinions shot up around the room and the team began a healthy debate. I was standing in the back of the room and, as things wound down, flashed both hands out several times to our VP of Sales who noticed and said, “Sean’s giving a pretty big number back there!” I spoke up:

“When I was a Sales Engineer I wouldn’t get on a plane for less than 7 meetings a day. So 25 or 30 a week sounds about right.” I got some nods as well as some eye rolls, like I had just said, “When I was your age…”

In hindsight, I could have articulated my vision more clearly at the time.

When you work for a startup you aren’t just working for a company but really building it. You’re creating something from nearly nothing. Zerto has thousands of customers and hundreds of partners and yet we truly are at the bottom of a mountain. VMware, the leader in server virtualization today with the vSphere product family, boasts over 500,000 customers globally. Zerto software also supports Microsoft’s server virtualization platform, Hyper-V. We’ve extended support for disaster recovery to Amazon Web Services and Microsoft Azure, and we’re currently working on ways to get virtual machines back out of those two public clouds. In fact, “bottom of the mountain” doesn’t quite describe it.

It’s more like this:

everest
Mount Everest seemed like an appropriate metaphor

Since the business review a few Sales Managers and SE Managers have asked exactly what I meant that day. This has been and continues to be my answer: At Zerto we have an enormous mountain of opportunity ahead of us. VMware alone has over 500,000 customers. Remind me again of how many we have? It is not a small number, but it is nowhere near five-hundred thousand. It’s not 100,000. We aren’t even 20% of the way there. And that’s just one platform! We’re cross-platform, baby! We aren’t yet climbing the mountain, we’re on the long and glorious trek to the base of it. Have breakfast with a partner. Have lunch with a customer. Take a potential customer to dinner. That’s three meetings right there. That is three steps closer to the base of the mountain. This is the warm-up. Stretch your legs, take in the view, you’re in for a wonderful adventure.

Every day hundreds of Zertonians around the world wake up with one goal: create a world of uninterrupted technology for businesses & people. Think you have what it takes? We’re hiring hundreds of people this year across dozens of roles. Come join us on our amazing journey.

http://www.zerto.com/careers/open-positions/