Sunday, May 7, 2017

He Ain't Heavy, He's My Data

Man collecting data into funnel

The explosion of data in the recent years has had some knock-on effects. For example:
  • Data theft is far more prevalent and profitable now than ever before. Ever heard of Crime-as-a-Service?
  • There is now more pressure than ever before to modernize our applications to take advantage of the latest advances in DevOps and Cloud capabilities.
But the problem is that data growth is actually encumbering most companies' ability to modernize applications and protect customer information. The effect is exacerbated in environments leveraging containerization where application stacks are spun up in seconds and discarded in minutes. Through no fault of their own, the DBA/Storage Admin can't even initiate a data restore that quickly. This has painted data as the bad guy.

Thief hiding behind handcuffs

The consequence of this is that Dev/Test shops have moved towards eliminating the 'bad guy' by using subsetted or pure synthetic data throughout their SDLC. After all, it kills two birds with one stone: Data is small and easy to get it when they need it, and nothing of value exists to be stolen.

But the implication of this well-meaning act is that application quality decreases and their application projects are just as slow, if not slower, than before. Their use of non-realistic datasets results in an increase in data-related defects. Then they try to combat the self-inflicted quality issues by creating a whole new data program lifecycle around coverage mapping, corner cases, data quality, data release, etc. The net result is that they spend at least as much human and calendar time on data, as they did before...yet they will still have self-inflicted data-related quality issues.

We need to stop the madness. Data is not the enemy, rather it is the lifeblood of our companies. The true enemy is the same enemy we have been tackling with DevOps: Tradition. The traditional way that we have been dealing with the culture, process, and technology around data is the enemy. At Delphix we help our customers quickly flip this on its head and eliminate the true enemy of their business. By enabling our customers to provision full masked copies of data in minutes via self-service automation, they now have data that moves at the speed of business. Their applications release over 10X faster, their data-related defects plummet, and their surface area of data-risk decreases by 80%. And one of the beautiful things is that, in most cases, Delphix is delivering value back to the business inside of two weeks.

When you only address the symptoms of a problem, the problem remains. Data is not your enemy; serving data like you did for the last two decades is the enemy. Your data is more-than-ready to be your business-enabling partner, you just need to unshackle it with Delphix.

Wednesday, March 22, 2017

The Missing Ingredient

Last week, Delphix held its annual Company Kickoff (CKO). It reminded me of what makes Delphix such a fantastic company, and energized the whole company about what’s to come for this new fiscal year. There are many observations and takeaways, with a lot to share, so I’ll break this into two or three blog posts. First allow me to share some personal reflection on the past year.

Having been at Delphix for over three years, I have enjoyed the ride that being a part of a disruptive startup has to offer. There have been successes, and there have also been setbacks. We have had some easy wins, and we have also had some scrappy battles. While there is no doubt of our success, being the pioneers and masters of our space, or the value we deliver to our customers; I couldn’t help feeling that we were lacking something. We were a company on the cusp of greatness, yet that that golden ring seemed to be just beyond our fingers. Of a surety, something had to change. And 2017 ushered in an abundance of change: we filled all of our senior leadership vacancies, had a few organizational realignments, and even product realignments. And we are definitely better for it; people were excited, bustling, and busy. Yet coming into this new fiscal year, something still felt like it was missing.

The evening before the official start of CKO, we had a welcome reception for everyone who had already arrived. The only way for me to describe the scene and to give it justice, is to liken it to distant family reuniting to celebrate a holiday. And why not such a description? For us at Delphix, this is a time of celebration: we reflect on the previous year’s tremendous accomplishments, and also share our plans and dreams for the future. And true to the analogy, there were many warm embraces, huge smiles, and boisterous bursts of laughter between those that are normally separated by thousands of miles. We had food, drink, and friends. Yes, indeed this was a joyous event.

The next day we our CKO was kicked off by our CEO, Chris Cook. Our event opened up with a video of Chris taking a car full of Delphix employees on a “Carpool Karaoke” drive from our HQ in Redwood City, California to the CKO location. The video showed a more personal side of Delphix, and the laughter among the Delphix family was infectious. As the video ended and Chris took the stage to an standing ovation, I looked around me to see everyone with grins from ear to ear. It was at this very moment I realized that the transformation of Delphix was happening, and that I was witnessing a metamorphosis before my very eyes. For the first time that I had ever witnessed, all of Delphix were in the moment...together. This was my first aha moment (more on that later).

As everyone returned to their seats, Chris began to share with us “The Delphix story,” painting a vision where data is no longer the constraint, but data moves at the speed of business. He shared with us what a world looks like where data is as easy and instant to conjure as a snap of the finger. He then challenged us to make that vision a reality, to execute on our mission to reduce the weight of data, accelerate the pace of discoveries and breakthroughs and inspire more aha moments.

Wait. What are aha moments? Chris explained that this is the moment when people discover something profound where they previously had no knowledge. This happens a lot with Delphix customers. It is so pronounced, that you can see it physically emoted in many cases. To be honest, this is one of the best parts of my job. To see someone finally grasp Delphix and then get slammed with the realization of the huge impact Delphix will have on their lives is absolutely amazing. I have seen people go wide eyed, shake their head in disbelief,  get out of their seat and walk around, and just stare at me with their mouth agape. Watching those life changing moments are just as life changing to me.

This was my second aha moment. Chris was ushering in a fundamental shift for Delphix. It’s not our job to sell software; but instead it’s our job to change our people’s lives for the better with our technology, unlocking as much innovation and potential as possible while freeing them from the shackles of their data constraints. This is a mission that I cannot refuse.

After his talk, Chris brought in former Blue Angels pilot, John Foley, to speak to us that morning. John shared some amazing stories about his exploits as a pilot, including functioning as a goodwill ambassador during times of heightened tensions between the United States and Russia. He taught us the value of his #gladtobehere initiative, where a heart of thanks and gratitude are the bedrocks of character and success. But the thing that stuck out the most to me was the precision that was needed to achieve the level of excellence that makes the Blue Angels the best. Yes, that precision takes thousands of hours of practice, teamwork, dedication, and skill. But what set the Blue Angels apart were their unity in focus and purpose. The hours of daily drills where they would sit in a briefing room and talk through the day’s flight, literally turn by turn, maneuver by maneuver. Why? Because they are all committed to precise execution; the consequences of even slight miscalculations could be catastrophic. That was their promise to each other: to be of one mind, focused on their execution and of those around them, in order to collectively be the best at what they do.

And it was the conclusion of John Foley’s presentation that I realized that we finally had what we had been missing: one vision, one mission, one focus, one promise, one team…Unity. We have a lot a unbelievable talent at Delphix – you won’t find better anywhere else. We’ve been been doing our best individually or as small groups, and that’s gotten us to a great place. Now that we’re unified, we are poised and ready to transform the way the world deals with its data.

Friday, February 24, 2017

NMFP: The cancer from within

Not my problem (NMP) - (n)
  1. a statement, or position, of apathy expressed by those who perceive they are external and unaffected by a negative predicament. While sometimes warranted, it is typically uttered by those who perceive themselves as powerless; can’t be bothered; are too lazy, or are selfish non-contributing leeches. See also “complete cop out”, and Not my <fluffy> problem (NMFP)
  2. an attitude that will stymie attempts to implement DevOps in your organization and will thwart success
  3. (archaic) Actually not your problem

The phrase “Not my Problem” may be an english turn of phrase, but the concept is universal. In Poland, they have an idiom “Nie mój cyrk, nie moje malpy”, which translated to english is “Not my circus, not my monkeys ( a nod to my friends Daniel and Piotr).” Some of our oldest stories bear witness to how timeless NMP is. In the the biblical story of Cain murdering Able, God approaches Cain afterwards and says “Hey Cain, I can’t find Able. Do you know where he is?” Cain’s response is the famous “Am I my brother’s keeper? (NMP)”

We have all heard it, and I am sure we have all said it ourselves, many times over. Let’s be honest with ourselves and reflect on our own actions. I am sure we can all recall ample examples of this in our personal life. But how many times have we uttered that phrase to justify our own inactions at work?
  • You’re in engineering and sales slump: “That’s what Sales makes top money for.” (NMP)
  • Someone on your team just had a major setback in their project: “I got my own projects to handle” (NMP)
  • You see an area at work that is in critical need of improvement: “That’s not in my job description.” (NMP)
  • A colleague you work with is having an obviously hard time today: “I stay out of personal business.” (NMP)

And the ringing bell of condemnation of our actions is the stinging fact that we would almost never have actually said that to the people we witnessed being affected.

So what does this have to do with DevOps? I attribute NMP to be the #1 culture killer; and without culture, you don’t have DevOps. How can you have a culture of learning and sharing when people are only out for themselves? That is what NMP implies. People who have an NMP attitude are like a cancer eating your good culture from the inside out.

I recently witnessed this in my second youngest son’s basketball team. When a certain kid wasn’t at the game, the team would perform, even under pressure. They might lose, but they would be in the fight the whole time. If this other kid was at the game, a decent street ball player by all counts, they might win, but they usually lost by heaping amounts. Nothing was ever his fault, and when others on his team would make a mistake he would be the first to yell at them. As soon as they would be down a few points, it would be worse and his bad attitude would spread to every other kid on the team (except my son, thankfully). They would end up losing by many points when this happened, even to teams they had beaten handily before. Why the coach ever let him play, let alone play point guard, is beyond me. But his lack of a sense of team and his own self-glorification hurt his teammates more than him. He deserved to lose, they didn't.

But, we don't always get it wrong. The other day, I was speaking to a dear friend, and fellow DevOpserati, Jude Seth a Client Architect at MuleSoft. He said they have a culture, written, understood, and embraced that forbids “Not My Problem” from even existing in their vocabulary.
  • If sales are slumping, everyone feels the burden to brainstorm and contribute to help generate pipeline or accelerate deals in play. Sales isn’t underperforming, WE’RE underperforming.
  • If someone on a team has a major project setback, everyone chips in and feels compelled to help get it on track. Your project isn’t late, OUR project is late.
  • If there is an area at work where someone feels there is a gap, they get to work on addressing it themselves, pulling in others as needed. “You don’t need to do something, I need to do something.”
  • A colleague is having a rough day, they make sure to help them with their daily work, perhaps do something nice for them, or have them go take some personal time. When you’re hurting, WE’RE hurting.

It is this kind of change in ownership of success and failure that has to happen in order for historically separate groups can work as one. It can no longer be an Ops or Dev or QA or InfoSec issue. It has to be OUR issue.

I have seen many companies and teams eaten up with the cancer of NMP. You can do all the team building events and “trust falls” that you would like, but when it counts, will you be the one who quietly tiptoes out the door while your teammates work to resolve an issue? Because it is this behavior that causes the whole thing to collapse. It can’t be “All for One, and One for All (except Bob because he’s kind of a selfish jerk).”

If this brings to mind someone on your team what are you going to do to address it?

Or is that not your problem?

This blog was inspired by a great colleague and companion of mine, Steve Karam. We too have a great culture of ownership at Delphix, and Steve embodies it perfectly. This mega-genius is constantly at the forefront of tackling different issues at Delphix and is always quick with a kind word, helping hand, and a smile. When I think to myself, “NMFP”; my conscious tells me “Don’t be a jerk, be more like Steve.” Follow this beautiful human being on twitter @OracleAlchemist on his blog.

Sunday, January 29, 2017

Want to be Great? Always Touch the Fantastic Line

Want to be great? Touch the fantastic line!
image courtesy

 Recently, I was watching my youngest son's (10 years old, and we'll call him Mitty) basketball practice. The practice was full of the standard fare: layup drills, free throws, and every kid's favorite: wind sprints. In case you have never had the pleasure, wind sprints are when you line up at one end of the basketball court and sprint to the free throw line; you then bend down and touch the line and run back. As soon as you get back, you turn around, bend down to touch the line, and run to the  half court and back. You repeat the sequence with the far free throw line and back, and then to the far end. Sounds like fun, right?

Image of suicide drill
image courtesy of

During each of the drills, my son was leading the pack. Well, leading all but the wind sprints, that is. Like most parents, I am super proud of all my children; but it is an absolute fact when I say that Mitty is an exceptional talent. He is frequently recruited and plays on a travel team. The only thing that holds Mitty back is that all that talent is packed into a short stout package. So, I can guarantee to you that he will make every layup, sink most free throws and jump shots, and come in near last on wind sprints. Be that as it may, I found myself watching him in awe and really contemplating how he could still be so exceptional even though he was short and slow.

The answer came to me while I was watching the wind sprints. As the kids started their sprint to the first foul line, as expected, Mitty is bringing up the rear. The fastest kids are already halfway back before he reaches the line. He is running his heart out. He bends down and touches the line, and sprints back. By the time he gets back to the starting line and touches it, the other kids are already off toward the second line. The fastest kids start to separate from the pack. My eye is drawn to the kids as they reach the half court line. Some of them are in a dead heat and they quickly turn around at the mid court line and swipe their hand at the ground as they start to sprint back. As Mitty reaches down and touches mid court line, some boys are getting ready to hit the starting line for their third sprint.

 As they turn around some of them don't even feign much of an effort to touch the line. They are too concerned about losing the race. On the turn around and the last sprint, near all of them don't touch the line. But Mitty is still running as fast as his legs will take him and he is sure to touch the line every time.

And that is when it hit me: Mitty is great at basketball because doesn't pursue the win. He is great because he pursues personal excellence. The win is merely the fruits of that pursuit. Mitty is exceptional because he makes sure he touches the line, every time. It would be so easy for him to just stop, bend over a little bit, and then turn around to run again. Everyone would understand after all: He's a star player in every game, everyone one loves him, and he wouldn't be hurting anyone by doing it. Any but himself, that is. And this pursuit extends off the court to nearly everything the young man does. Any given day where the weather cooperates, you will find him outside practicing. He makes sure his mom has him at least 15 minutes early for games and practice   He studies his spelling words, until he knows them perfectly. He even takes his jump rope outside, unbidden, to get jumps in just because someone told him it would help him get faster. He does whatever is needed to be done in order to ensure he is in the best condition to win, even when no one is watching. He touches that fantastic line, every time.

And I see how this extends to being successful in life and in business.  It is critically important that you do not pull up short, but that you go every last inch of the way.
  • Do you cut corners in your craftsmanship, or do you touch the line?
  • Are you commonly late to meetings, or do you touch the line?
  • Is ensuring customers see the value you promised them someone else's problem, or do you touch the line?
  • Do you leave mentoring people in your company to someone else, or do you touch the line?
  • Do you see something wrong and remain silent, or do you touch the line?
  • Do you walk by garbage in the floor of the office, or do you touch the line?
  • Do you let a coworker struggle, or do you touch the line?

There was a time in my life where I would not have "touched the line" on most of those. And I was rather unsuccessful then, as well. But now I enjoy a modicum of success, and I can say that I would feel a great deal of shame and disappointment if I were guilty of any of those things. Since that day, there has been a few times where I would have fallen short of my standard of personal excellence, but the image imprinted in my mind of Mitty reaching down and touching that line compels me to do the same. May we all strive to always touch that fantastic line of distinction, even when no one is watching.

Thursday, December 15, 2016

Minding the [Data] Gap

Mind the Data Gap
I am fortunate enough to find myself in London, England once again this year. If you have been to London and have ridden "the tube," then you are familiar with the phrase “Please mind the gap.” For those who may be unfamiliar with this phrase, it is repeated at every stop on the train/subway to remind departing passengers to not step in the space between the train and the sidewalk. And, like most constantly repeated sound advice, we tend to hear it the first time, and then drown it out. And, true to form, ignoring that advice usually comes back to bite us in the end. This is what almost happened to me today as “the gap” was twice as big as it normally is. I have never been so thankful to have such large feet.
The events played over and over again through my mind on the remainder of my journey back to the hotel. And then the thought hit me: this is exactly what happens in our SDLC (though often with a more unfortunate outcome). We have learned to live with the peril of old, stale, subsetted, or purely synthetic data (the data gap) in our day-to-day lives and completely forget about its presence...until it is much bigger than we assume and almost kills us (or in the least causes us some embarrassment and bruises).
We have acknowledged the data gap in our SDLC and have managed to just work around it ... that is, until we don't. All of us have experienced injury from the data gap in our projects. Here are some typical injuries:
  • We plan for the two week database provision time, but then it takes 4 weeks. Project delay and cost overrun.
  • We plan for three days for a database refresh, but it takes 5 days. Teams waiting, features drop. testing cycles drop.
  • We don't plan refreshes, so our projects don't suffer downtime; but the six week/month-old data caused us to miss detecting a P1 defect.
  • We program back-out scripts/steps to reset our dev/test environments to avoid 5 day refreshes; but they unknowingly fail, introducing bugs and productivity loss.
  • We don't mask non-prod copies, because masking is hard and takes too long. Dev gets compromised.
  • We just run pure synthetic data in non-prod but we miss corner-cases; introducing bugs into late-cycle dev or into Prod.
There are even more data gap pains we have all faced around processes like subsetting and break fix activities. Just like in my tube experience, we knew the gaps were there. In fact, we counted on the gap to be there, but in those moments the gaps were far larger than we planned. We planned to march forward with our data in place, but instead we plunged into the abyss.
While Delphix can't heal every peril in your SDLC, let's examine just a few of the places where Delphix can remediate:

Provisioning new data

Today, if you are like most traditional shops, you wait days or weeks to get new environments, and additional days/weeks to get those new environments provisioned with data. If you are a more modern DevOps/Automation shop, you can get environments in minutes, but you still wait hours or days for data. After all, even if you automate the request, copying/transferring 60TB of data only happens so fast (thanks, physics). With Delphix, you can eliminate the words "days", "weeks", and "hours" as descriptors for waiting for data. Yes, that is even for a 60TB database. This can either be done ad hoc by the developer/tester/DBA via the Delphix self-service tools, or can be integrated right into your automation/DevOps processes with very little effort.
In the below diagram, I depict a situation where you are already using configuration automation, such as Ansible, Puppet, Chef, or Salt Stack to build your infrastructure and supporting applications. In this case, you can easily tell those tools to automatically call Delphix to provision the data after the infrastructure is in a ready-state.
Flow diagram of provisioning data with and without Delphix
Fullscreen image here

Refreshing Data

The constraints that afflict data provisioning in your environment likely afflict data refreshes in your environment, though in some cases the constraints may be somewhat lessened (days, instead of weeks). The same technology that Delphix uses to provision environments can also be applied to refreshes. That means that refreshes take the same amount of seconds/minutes that it took to provision the first copy. The same self-service and automation capabilities that were available to provision, are also available to refresh. Also, Delphix stays in near real-time sync with production. That means you can refresh your non-prod copy from 3-seconds-old production in just a few minutes time, at will. In the time that it would have normally took you to shoot your friendly DBA an email to request the refresh, you could already have the data. How does that impact your project timelines? If every time you do a pull from git, or trigger a commit gate on TFS, etc. it automatically refreshes your database (including applying any DDL/DML that needs to occur), how does that affect your quality?
The below diagram depicts a real account of one of our Wall Street financial customers. Because production data was cumbersome to deliver to non-prod, development would occur on months old environments. Changes to production occurred outside of development, courtesy of hot fixes, etc. Over time, this would add more and more inconsistencies between production and development data which resulted in more and more bugs making it to production. Routinely refreshed data in development results in more defects being fixed early in the SDLC where they are easier to fix. Here I show refreshes happening on a weekly schedule, but they could be set to any interval or trigger by some other tool such as a git hook.
Fullscreen image here

Resetting Data

Some tests are destructive by intentional design, and some tests are unintentionally destructive. In either case, you require a way to get be to a "test-ready" state. That really leaves only a couple of choices: either refresh the data, or back out of the changes. But, backing out of the changes implies a couple of very important constants. First, you have to be aware that changes were made to your data. If your development or tests were not designed to be destructive, are you even scrutinizing that Field A2354 on Form 234 now points to a different column in table XYZ? You simply don't know what you don't know.
But, if you are running intentionally destructive tests, are you sure you are backing out of all the changes? How much time and energy are you spending on your back-out/reset procedures? Do you subject those scripts/procedures to the same level of QA as the application you are developing? If you are, I commend you. But, there is still a better way. Once your non-prod environments are virtualized in Delphix, you can have crash-consistent copies of your applications that are as easy to access as rewinding as a movie on Netflix, or flipping pages on your Kindle. You have already provisioned your data with Delphix in minutes. You do some development that did not yield the results you wanted. Just click "Rewind" to go back to the point in time you want. This can either be a literal timestamp, or something more canonical, like a bookmark titled "Step 5 complete." This process takes just about as long as it takes to restart your application/database. If you no longer have to develop, test, and maintain reset scripts, and the reset happens in minutes, what productivity and quality gains are delivered to your projects?
In the diagram below, I have depicted a typical process where you are testing the application of package updates to a composite application with multiple data sources or an ERP system, like SAP. In a traditional test, if you are applying a series of SAP packages and one fails catastrophically, you likely have to wipe and start from scratch. This process takes weeks. Our customers that use Delphix for SAP are able to revert the last successful step in minutes and are ready to resume their testing with the click of a button.
Flow diagram of resetting test environments with and without Delphix
Fullscreen image here

Data Masking and Anonymization

Security is paramount to protecting our businesses, missions, patients, and consumers. Non-production copies, with few exceptions, should never contain sensitive data. I know that we all know this; yet we all have worked (or are working) somewhere where banking/patient/customer information was strewn about in many places. If masking was easy, everyone would do it, everywhere, all the time. With Delphix, masking is easy. Furthermore, with Delphix, Agile Masking for non-prod copies can be automated eliminating the potential for a process breakdown whereby a developer gets an unmasked copy of production. Leveraging role based access control, every time a developer clicks "provision," "refresh," or "rewind," his request is supplied from a pre-masked copy of production. Yes, pre-masked. So, the tax has already been paid for that 8 hour masking job by the time your developers get into the office at 8AM, and they have fresh masked data available from the previous day's close. Delphix Agile Masking is easy to setup and use, requires no programming expertise, and can even analyze your data for possible sensitive information. With the complexity and time constraints removed from masking, how can you afford to not mask anymore?
In the diagram below, I show a typical process where a new copy of masked data is requested and the time and manual touch points that it takes before the data is delivered. In the Delphix scenario, security can establish and review a masking policy that is automatically applied by Delphix. Delphix automatically updates with a masked copy of production on a specified interval. At any time, and without impacting the data delivery chain, security can review any of the automatically masked copies to ensure compliance and satisfy audits. The requestor only has access to request data from the certified masked copy and can get it delivered via self-service in minutes. This application of masked data delivery can be applied to any of the above scenarios I described, as well.
Flow diagram of masking data with and without Delphix
Fullscreen image here

These are just a few of the scenarios where Delphix can be inserted in your SDLC. I have previously blogged about our customers that leverage Jenkins or SNOW Orchestration as orchestration tools to call Delphix provisioning to complete their CI pipeline. They key point is to look at your SDLC and identify points where you are waiting. If you are waiting, it is likely for data. If it is indeed data for which you are waiting, then Delphix can help. Delphix is Data Delivered.

Tuesday, December 13, 2016

Fundamentals of DevOps: The Servant Leadership Gene


I have been privileged to be a part of the technology sector these last two decades. In the last four years, we have seen a fantastic shift in ability for companies to innovate, thanks to what has been aptly called "DevOps".  Drastically oversimplifying, DevOps is the unification of the Operations and Development groups inside of an organization; leveraging Culture, Automation, Lean, Measurement, and Sharing (CALMS) to rapidly accelerate software from Development to Production. Companies like eRetail startup Etsy have used DevOps to rapidly develop their products and capture huge market share; likewise, DevOps has also brought light speed agility to established giants such as Amazon, Apple, Facebook, and Fidelity to be able to deploy thousands of times a day. In the face of such demonstrable results, it is uncertain how companies that aim to compete in the marketplace can do so without embracing DevOps.

And since software rules the world, we tend to look to software to improve our situation. Indeed, software has allowed us to automate, measure, and lean "all the things" to achieve some amazing results. Yet, every day companies seem to be waking up to the realization that software alone isn't enough. Just a simple google of "DevOps failures" gives several pages of new listings from the last month. It seems that these companies are just late to learn what Patrick Debois discovered near the beginning of the DevOps movement: “DevOps is a human problem”. Fittingly, the IT Revolution Press bookends the DevOps acronym of core principals with two people-centric items: Culture and Sharing. But, even some of those that have put people first are among those who have failed. So then, what is the missing ingredient that hinders IBM's success with DevOps and enables the Etsy’s? I am afraid I don’t know of any spell to conjure, but I but my meditation on this subject has led me to three magic letters: DNA.

In reading numerous interviews of some of the DevOps Elite, I have noticed a recurring pattern: Servant Leadership. Ken Blanchard breaks down Servant Leadership into a threefold role: servant, steward, and shepherd:

The Servant – seek to meet the needs of others
The Steward – take great care and consideration of what has been entrusted to you
The Shepherd – protect, guide, and nurture those under your sphere of influence.

In the preface of The DevOps Handbook, Jez Humble, Gene Kim, Patrick Debois, and John Willis give brief interviews as to how they got involved with DevOps. Though I have only met Gene Kim a couple of times, and know none of them personally, I do not believe they were motivated by a quest for glory or self-interest. The common theme among their interviews was that they saw their peers struggling and, thus, they felt compelled to find a better way to help their community. This required many years of swimming upstream against a long-established IT culture of anti-patterns rewarding fiefdoms, silos, and lone wolves. For those of us who have been in the industry any real length of time, we have either been participants or victims of this culture (or perhaps both).

Servant Leadership, isn’t that just culture? No, though if you have a culture of Servant Leadership, that is a beautiful thing. Culture is the result of group action and thinking, and each of the aforementioned pioneers had to initially go it alone. Such was their isolation, that in their brief few paragraphs, each of them noted the moment when they encountered like-minded individuals. The realization that you are not alone in the world is a life changing moment.

What then would make them do an about-face and sacrifice of their own selves to swim upstream for the greater good? I submit that it is the same thing that drive the salmon upstream: DNA. Not that these individuals were endowed with some sort of “altruism” gene; but somewhere along the way these individuals had developed a sense of purpose that extended beyond themselves. This could have been instilled in them in the home as young men, or perhaps a result of counseling from a great mentor in the workplace.  Subscribing to Dan Pink’s theory of what motivates us, because of that purpose, they leveraged their autonomy and mastery in the pursuit of the solution to this complex problem.

And I think this is a common missing component across the Technology-sphere, whether you are “DevOps’ing”, or not. One cannot simply list “Servant Leadership” as a core value in the employee handbook and reap the rewards in a few quarters. To truly get your organizations to go against the current, begin to openly collaborate and share, and work to a common business objective; you are going to have to rely on individuals that have the Servant Leadership DNA. Even if this requires a transplant. This is needed at all levels, or your servant leaders will leave. With top-level servant leaders in place, your front-line servant leaders will have the support they need to continue to face cultural adversity for the sake of everyone under their watch.

I believe the heart of a Servant Leader can only be taught by example. I am the truth of that statement. I owe Dave Lavanty, now VP Public Sector at Adobe, a debt of gratitude. When he met me, I was a quick-tempered lone wolf upstart. I am certain that I was a challenge that caused him to lose a few winks on occasion. And the entirety of the lessons he taught me still haven’t fully soaked in. I am still learning from those past lessons today. If it wasn’t for his persistence of Servant Leadership towards me, I am certain that my current state would be far worse than I enjoy today. And because of this truth, I do my best to be a servant leader in all things I do, both in and out of the workplace.  

Wednesday, October 26, 2016

Data Delivery: Do you have the Ch(at)Ops?

Recently, I got the privilege to engage in a lively conversation with a Delphix customer from Wall Street. The conversation was around all the ways that data virtualization via Delphix has improved their day-to-day operations, SDLC, TDM, CI/CD, and DevOPS initiatives. They also shared how Delphix has fundamentally catalyzed their ability to deliver and innovate at unprecedented levels. As we started discussing the "Art of the Possible" for their journey with Delphix, they asked about integrating Delphix into their ChatOps environment. Based on that conversation, I submit the following:

Links I reference in my video:
My Github with examples
Meet Will, the friendliest, easiest-to-teach bot you've ever used.
Delphixpy Tutorial 1
Delphixpy Tutorial 2
Delphixpy Tutorial 3