A few weeks ago, I wrote about the importance of taking on the persona of a hacker to break down all aspects of our technology, to ensure it is secure and reliable. This article is about makers, the opposite of hackers. Where hackers break, makers create. Maker culture is a real phenomenon, if you are completely unfamiliar with it, read-up on it here.

The gist of it is this: There is a growing movement of people that prefer a do-it-yourself approach to problem solving vs. waiting for some else to solve problems for them in the form of commercial product offerings. The do-it-yourself approach isn’t an individual effort, but is community-driven. Makers reuse bits and pieces of others’ inventions to create something new and novel.

The influence of maker culture on the world of enterprise technology is obvious for application development. Look no further than open source, GitHub, and library reuse to see how this plays out. Because that is so obvious, I’m going to focus this article on the influence of maker culture on infrastructure engineering. It’s less obvious, but extremely important to discuss and foster.

Infrastructure engineers’ primary job is to implement and integrate commercial technology products into the existing enterprise environment. On the surface, there isn’t much “maker activity” involved in that process. Infrastructure engineers don’t typically make servers, network appliances, operating systems, databases, or middleware technologies from scratch (or parts).

Those technologies come out of the box and are installed according to the manufacturer’s recommendations and industry best-practices. The core platforms are generally accepted to be commercial. The opportunity exists in the next layer up. There is an entire ecosystem of products that extend platforms for monitoring, automation, management, enhancement, integration, reporting, analysis, compliance, and security.

For ease of discussion, let’s call these “tools.” When it comes to tools, infrastructure engineers have a choice: Do I source commercial products, or do I roll my own? Fortunately or unfortunately, there is one ever-present catalyst to reliably unleash the maker-instinct in infrastructure engineers: poverty. It always seems easier to buy commercial products that solve problems, but sometimes the money isn’t available. When infrastructure engineers have more time than money, they invent.

My maker story

Here’s my personal story: Back when I was a Citrix engineer, there was design limitation in every Citrix environment that plagued enterprises everywhere: User Profile Management. Windows came with Roaming Profiles that simply didn’t scale reliably in enterprise environments. At the time, there were a number of commercial products that specifically addressed this gap and there was an entire market for 3^rd party User Profile Management solutions. I had the problem, but didn’t have the budget to buy any 3^rd party solutions.

I started researching the internal workings of windows profiles. I learned everything there was to know about how they load and unload, how they can be ported, and how they can be manipulated within the windows registry. I searched community forums for script samples and techniques for performing certain actions. Through several iterations, I developed a custom User Profile Management solution. I didn’t write a single line of code, and didn’t develop a product, but I built a comprehensive solution that fixed the problem and scaled. I implemented my custom profile solution at both GMAC-RFC and RCIS. An evolved version of it is still in production at RCIS today.

I remember taking sales calls from 3^rd party vendors of commercial user profile solutions after I made my own. I explained to them how I solved the problem, and their response was always something like: “what you did is possible, but our customers aren’t willing to do that much scripting, and don’t possess that level of understanding of Windows internals.” While I drove the solution, I needed significant contribution from the virtual communities of Citrix engineers around the world to make it work. I didn’t make it all by myself.

Now, onto leadership

Bob Johansen, author of Leaders Make the Future identifies the Maker Instinct as one of his ten leadership skills for the future. “Many people don’t realize their own maker instinct and potential. It must be recognized, valued, and nurtured if it is to become a leadership skill for the future. Beyond do-it-yourself, leaders need to nurture do-it-ourselves. The maker instinct must be amplified by connection.” It is critically important that infrastructure leaders encourage the development of infrastructure tools and automation scripts. It’s hard to start unless you have the fundamentals.

When I started as an engineer, batch files were king. Then batch files were replaced by the more powerful, VBScript. I was a VBScript guru. By the time I was leaving my role as a hands-on engineer, PowerShell was starting to displace VBScript. If you are network engineer, Python may be your thing. If you are a Linux engineer, Bash or Perl. If you are a Middleware engineer, then you better know JSON and RESTful. You have to learn the basics first, then use it before you lose it. Simple web searches render treasure troves of free samples to do common administrative automations. But don’t just take from the community, make sure you share your own creations to enrich others.

Value the process over the product. Automating manual processes and creating tools yourself that commercially cost $10,000-$100,000 or more is very satisfying. The joy and motivation is intense and contagious for a team. Not everything you make will work, but the process of trying is still worth it. I see the maker instinct all over the teams I lead at CHS and it makes me very proud. Not only does it save time and money, it’s just really fun.

I’m going to close this article with a leadership thought on the maker instinct: “In times of great uncertainty, the maker instinct releases power. When leaders feel overwhelmed, they can become passive. It is much better to make something than it is to sit back and wring your hands. Leading is making.” – Bob Johansen, Leaders Make the Future: Ten New Leadership Skill for an Uncertain World

Have some great maker stories? Please share them below! If you like my blog, please share it with your colleagues!