I love homebrewing. I love it not just because I get to enjoy the rewarding, liquid delight at the end, but because I get to create. I create great beer and sometimes not-so-great beer. But the creativity extends far beyond just brewing a batch of beer. It reaches deeper into what facilitates making the beer. I’m talking about the plumbing, the pumps, the vessels, the burners and the chillers. I am what some would call a brewing hardware junkie.

My profession is in technology. I’m a solutions architect/consultant/CTO’s best friend. It’s my job to solve difficult problems, get thrown into challenging situations and extinguish political fires. I analyze technology beyond its technical merit, I create evaluation models and charts and graphs, and I really dig into how well it performs – all from the perspective of the business. This is my job and I’m very good at it.


When I can’t brew, I need to satisfy that urge to do something brewing related. I spend hours combing through social sites for #homebrew and #homebrewing, often day dreaming about when I’ll turn pro! I have bookmarks to stainless steel fittings, optimum pump orientations and HLT kettle conversions. My YouTube channel subscription list pays homage to the homebrew DIY’ers. But it doesn’t end there.

Similarly, I invest the same amount of time and energy when researching technology. I gather whatever information I can from Google, LinkedIn, Twitter and blogs. I study training videos and attend webinars. I speak with fellow technologists at conferences and at local meetups. But it doesn’t end there.


When I find a new brewing method that seems improved over my current method, I create a plan to test this new process. I want to learn how will this process increase my brew house efficiency. Can I shave time off my brew schedule? Is less equipment required to accomplish the same goal? Will this new method mitigate the risk of contamination? I test the new method and compare the results to previous records. Some results are positive, some are neutral and some are negative.

Just like in brewing, technology needs to be graded on more than its technical capabilities. What operational efficiencies are gained? How difficult is it to manage? How likely is the vendor to execute on the product’s roadmap? What risks are introduced to the business with this new technology? Each of these questions and categories should be explored when conducting a proof of concept. Deciding factors are not about how well the technology works, but about how well the technology works for the business.

Sample results from a vendor evaluation framework.

Sometimes technical performance is not always enough to justify vendor selection. The evaluation framework goes beyond the technical and provides foresight into what it’s really like owning the product. Leave a comment if you would like to hear more about the evaluation framework.


The week of brew day, I validate my to-do list and review my ingredients. I’m focused, determined, and ready for whatever brewing mishap comes my way. I have wrenches, pliers, gloves, goggles, boots, clamps, hoses, ice and water. I have buckets, hop bags, grain bags, thermometers, hydrometers, refractometers and timers. All clean and ready to be put to work.

I review my to-do list during the weeks leading up to implementation, just like I do during brew week. I meet with peers, the operations team, technical leadership and the lines of business involved with the new technology. We review the results of the POC, train our staff, draft plans, formulate contingencies and make sure there are no uncertainties. A successful proof of concept arms you with the confidence to successfully integrate the new technology. This confidence manifests itself in various forms: test plans, run-books and low-level designs, updated processes and procedures, change management documentation and success criterion.


Whether you are performing a proof of concept or brewing a batch of beer, remember: research, prove and validate. These three steps will help you and your organization mitigate risk and achieve success.


Do you have an interesting POC story? Perhaps you have your own method or some tips to share. Leave a comment and share your successes, helpful tidbits or an anecdote when you wished time travel were possible.


How to Subnet – A Quick Reference

by Paul on October 29, 2012

I learned how to subnet way back in the way back but it’s something I rarely do. In those rare situations, I would do the work in something like Excel or Google docs and then validate my work with an online subnet calculator. I was in a training class last week where we needed to carve up a class C into at least 6 networks. One of the instructors asked the class if they could create the networks, provide the IP ranges, and specify the gateway and broadcast addresses. This is when I learned that many of the other students in the class did not know how to subnet.

I was planning to write a blog post about it but I think a visual reference would help illustrate how IPs are defined, where the mask comes from, etc. I saw this as a great opportunity to kill some time while traveling and play around with my new drawing app for the iPad: Grafio.

Here is the end result: How to Subnet – A Quick Reference.

I hope you find this reference to be a helpful tool. As always, I welcome the feedback and any suggestions for improvement.


It’s definitely a hard transition going from engineer to manager. What’s even harder is managing the team of which you were once a member. Just yesterday, you and your peers are commiserating about how much of an ass your boss is being. Today, you are the ass boss. This post highlights five super important things that I’ve learned since moving into my new management gig.

Don’t Panic

Just like it says on the cover of the book – don’t panic. There’s a reason why you are in this position. Someone clearly thought you have potential to be a good manager. Maybe you demonstrated solid leadership. Maybe you are great at getting shit done. The bottom line is this: You are here now so keep on doing whatever it is that got you to this point and everything will be OK.

Be in Control

Establish your authority, quickly. This is important: make sure it is YOU that is in control of the team. You need to recognize the difference between someone helping you and someone undermining your authority. Here’s a hint: If your gut tells you that someone is stepping on your toes, then listen to your gut. Chances are your toes are being crushed. Nip that in the bud immediately otherwise be prepared to deal with people going around you for a long time. Set the tone early and continue to do so, but exercise some caution: there’s a fine line between manager and dick-tator.

Get Personal

Schedule routine one on one meetings with everyone on your team. Establish the employee-manager relationship early. Talk with your team about their short-term and long-term goals, training, job satisfaction, and most importantly – ask them how they are doing. Then shut up and listen to what they are saying. Don’t interrupt them and if they ask you something, keep the answer brief and don’t ramble on. If you do start to ramble on, you need to recognize that the conversation just went from being about your employee to about you. Now you need to immediately turn it around and get them re-engaged. It’s ok to share war stories but do that after you get through all of the important stuff.

Remember Your Roots

Now that you are a manager, you’ll have no time to actually DO the technical work. This is a hard, hard habit to break. You will have the urge to do technical things from time to time. You need to be careful with this one because doing technical work is no longer your job – it’s your team’s job. However, you should keep up with the tech and try to get some lab time in every now and then. If that’s not possible, sit in on some technical design discussions with your team. Not only will this satisfy your burning desire to tinker with shit, but it will help you retain those technical chops that you spent years honing.

Let It Be

This is an easy yet super critical one – just let it be. Let your team do what they do best and get the hell out of their way. If you get the urge to “fix” something, don’t. The minute you start tweaking your team’s recipe for success, you instantly become “that guy.” Nobody likes that guy because he micromanages the hell out of things. Don’t be a micromanager, let your team be successful. If you are annoyed because your team is at the park with the MiFi working on stuff while soaking in some beautiful weather and you are stuck in the office…too bad. Get over it. Or go to the park and join them. After all, you are the boss…



Simple RAID Calculator

November 28, 2011

I mentioned in my previous post that I’m presenting at the inaugural PING Philly meetup and my topic is on sizing and configuring backend storage. One of the main points I want to stress in my discussion is the importance that IOPS have when planning your storage configuration. To help illustrate this importance, I created a simple RAID group […]

Read the full article →

Status Update and the PING Philly Meetup Group

November 25, 2011

The last few months have been insane. First, I rejoined SunGard Availability Services where I am leading an awesome technical team with the ongoing development of our Enterprise Cloud Service. Then I spent most of October studying for the EMC Information Storage and Management Exam. After I achieved the EMC Proven Professional certification, I decided to […]

Read the full article →

3 Design Considerations for Your vSphere 5 Auto Deploy Environment

July 28, 2011

This post focuses on design considerations for using Auto Deploy Server to provision stateless ESXi hosts. Here are the three topics that I’ll address: Placement of New Services (Auto Deploy Server, DHCP, TFTP, Syslog, ESXi Core Dump Collector) DHCP Reservations Dedicated NICs for ESXi Management Placement of New Services Auto Deploy has a few prerequisites: […]

Read the full article →

FastNFS: Mounting a NFS Datastore to Several vSphere Hosts with PowerCLI

May 3, 2011

I’ve mentioned before about how I really do not like repeating the same task over and over and over – ESPECIALLY when working in a GUI. One of those tasks is manually mounting a NFS datastore to dozens of ESX hosts. I wrote a powershell script (with some assistance from my friend Jason) to do […]

Read the full article →

How to Connect Iometer Workers to a Master Server Using VMware VIX

April 20, 2011

I spent a few hours this week assisting my team with some Iometer tests. After repeating the same steps over and over on the first two VMs (and looking at the other dozen or so VMs waiting in the queue), I realized that this is an ideal scenarion for some scripting. My goal was to […]

Read the full article →

Escaping from Multiple Reverse Telnet Sessions on a Cisco 2900 Router

April 13, 2011

I’m definitely not a network guru but there are many occasions when I need to configure or troubleshoot something. I like to learn as much as I can so I do not need to impose on others…repeatedly. From time to time, I’ll come across a helpful tip or trick which makes my life less stressful. […]

Read the full article →

Tracking a VM in a Nexus 1000v Virtual Network

February 9, 2011

In this quick post, I’d like to highlight a few helpful commands that will allow you to track a VM throughout the virtual network. All of the following commands are executed on the VSM. If you need to get a detailed look at your configured VLANs or to see if one is missing or not yet configured, […]

Read the full article →