The beginning of an epic journey

In this post, I’m going to discuss my personal experiences in the shift to code culture, why I think this shift is important and what is working for our team of SEs in the PacNW.

A while ago, when I first set out to join the presales ranks, one of the SE managers asked me what I did to help presales. While I don’t think anyone still has that question, it’s a thought I come back to often. As it stands, my influence isn’t always obvious. I love collaborative problem solving; I love to swoop in and save the day. I’m not a self-promoter. I talk to a lot of people about what they are doing, share ideas, connect like-minded people and insert my own ideas here and there. I plant seeds. Some grow, some die –it is fun to see how ideas evolve. I’ve been getting some encouragement to use my influence in a more obvious way and to share more. In the spirit of one of the books I have been reading, Let’s start with why. Why am I still at EMC? Because I love the challenge of building solutions for our customers through the use of cutting-edge technology and collaboration with some of the smartest people I know. I love helping people. I have the autonomy to do whatever I want to do in Presales –to define the role on my own terms. Yes, the SAS team is where my goal numbers come from, but I leverage technologies from all over the Federation to make that goal. I love creating synergies between our products. I dig technical harmony. All of that said, the Inside-Out version of my head looks something like: 30% angry Lewis Black, 30% soldier of my own revolution, 15% fiercely loyal friend, 10% Taz/that dog from UP, 10% wide-eyed dreamer and 5% wild child full of bad decisions. The things I say all come from a place of caring, even if they sound angry. I speak about my personal experiences to give context because I’m not a voice of authority in the field. These are my opinions based on my view from the ground. Join us, or don’t. This is happening either way. In this case, how you get there is less important than where you go. Here is my story.

This experiment for me really started with an account SE named Brian and his “Why engineers should code” event he put on with another SE in Boise. I watched, I listened, I felt like an idiot. THIS was the thing that I felt that the specialists should be doing. THIS is what I should be doing. I should be leading this journey for our internal teams and our customers. But man it has been forever since I’ve coded anything! (I don’t count scripts.) I started reading and trying things out. I built a bigger relationship with Brian. He was helping me build my own WHY… and then he left a month later. I’m ashamed to admit it, but at that point I started to have a crisis of faith. It’s been a big transitional year for me both personally and professionally –and that transition is far from over. I struggled to figure this stuff out on my own. I read books and blog posts, but I’m a working mom with “keep the lights on” demands. Spending hours beating my head against a wall over a coding issue can take me weeks. I needed a way to find some quick wins. I needed some guidance. I kept thinking I had to pick up multiple languages and learn Chef, Puppet, OpenStack, Hadoop and the eternal list of new cool things. I also struggled with my definition as a specialist. I told people: “I’m the not special specialist.” I should have fired my marketing department. In truth, integration specialist is probably a better classification. I can speak to a number of options in the federation portfolio as well as a number of applications outside of it. I can make it all work together. I tend not to do EBC’s and roadmap presentations. I don’t do many formal presentations at all. My strength is in fireside chats and POCs. There are people on my team that can speak to an item on my list better than I can, but I can speak to the full set and how they all work together with all of the battle scars. I’ve never been a product person. You’ll never see me at a single product company. I like to solve problems creatively. Products are just a piece of the puzzle for me. Nothing turns me into a mute-button sailor who throws things faster than a product call that says “do what’s best for your customer by selling more of <insert this one product here>”. We all have our buttons to push. My problem was that I had lost sight of my why.

For me, code makes sense on a few levels. My job has a lot of repetitive tasks that take up too much time from the sales cycle. This work is important to our business and adds value to the customers, but it could be done in an automated fashion without spending hours staring at my computer doing the mundane tasks required to get the 5 minutes of content that actually adds value. I could do a lot with the hours I spend waiting on Symmerge, FTP, MiTrends, etc. I need to operate more efficiently to remain competitive in my space. The more I learn, the more I realize that the world of cloud is all about “good enough” this means that the historical value of a given product leading the industry will decrease over time. With stateless applications and HA at the app level, fewer apps require the redundancy of my bread and butter work at EMC over the last 9 years creating multiple copies of a given dataset in multiple locations. The decline of relevance of my (previously) most important work knowledge is a thing I will be able to show with quantifiable data soon. The ability to integrate and solve problems is still important, the platform distinction, less so. I can choose to learn new tricks, or I can stick my head in the sand and wait to be forced to learn new tricks. Given the choice, I prefer to choose my direction over just going wherever I’m pushed. Our customers are experiencing the same issues. They need help. I read the Phoenix Project and found it so relatable that I was ready to stomp out and start my own revolution. But who do I revolt against?

The easy answer is anyone who would encourage me that this is just another fad and the job will never change –including myself. We have all of these great bloggers talking about code in a DIY format and they have some awesome suggestions. I will not regurgitate those. Here is a great example with info on what to read and where to start. (be sure to read parts 2 and 3). Even with all of the great resources at my fingertips and cutting out 10% of my time, I didn’t feel like I was making significant progress. My learning was disjointed, I was quick to pivot. I needed a community of people who were going through the same thing. I was aware of EMC code at the time, but I didn’t feel like it was a place for people new to coding -these were experts and I was intimidated. I was wrong, and it is super friendly and supportive community but I have found the most help and motivation in our local office. Things really came together for me when I was presenting a new curriculum idea for our evolution of Scott Peyser’s Big Data Community Outreach Program. Let’s take a look at the parts of the puzzle:

Phase 1: Last summer a local SE manager started the Innovator’s Symposium. “Grab a Raspberry Pi and make it do something -anything you want.” You have 2–3 months to show your results via presentation to the other innovators. The original audience was account SEs, but I joined in, along with some other specialists and SE managers. I missed the presentations due to vacation, but it was a lot of fun. I spent a month playing with Raspbian, coming up with cute little things for it to do and helping others with their ideas. The symposium is now open to any who want to volunteer. This year, the focus is on the Particle Photon. This is where the tribe comes from. This is a leader saying “Hey if you are interested in doing cool things, come let’s give it a try.” In the end, the people presenting a product are your tribe.

Phase 2: PacLabs bi-weekly. That same SE manager set up a bi-weekly meeting with food and beer to allow people to collaborate around code as infrastructure. These are the regular tribe meetings. People come in and talk about their challenges with customer solutions, product feature gaps, finding a way to automate mundane parts of their job, new technology topics, running away and starting a brewery… whatever comes up. This is an innovation culture. Present your idea, others challenge it, work through the idea, fail fast and try again. I’ve been sitting through these sessions just absorbing knowledge. I wrote a little web app. I have a lot to learn, but it’s a start. This builds a sense of local community, makes people accountable for their progress and gives them a safe forum to seek help. It also provides an environment that encourages focusing on one piece at a time, choosing your own path to success and shows that as an SE, you don’t need to learn everything about the “new stuff”. Start with one thing. Try. We have your back.

Phase 3: PacLabs Accelerator. This came from a discussion we had around how to get more people coming to PacLabs. The goal of this phase is to create an easy path to learning the basics. People from the PacLabs bi-weekly team create a focused learning experience and walk attendees through things like: how to use git/github, an intro to Nitrous/Heroku, etc. The goal is simply to make PacLabs accessible to all to build the tribe. It has the added benefit of allowing the developing PacLabs leaders to speak about their learnings in a safe environment.

Phase 4: Community Involvement. This one is where we start to see indicators of success: people are contributing to EMC {code}, leading code efforts in their accounts, more comfort with open source and Pivotal; it even bleeds into our community service programs. Right now, PacLabs has 2 code contributors, both of which are leading coding efforts in accounts. One of them started a version of PacLabs with their customer. The other has used code to bridge product gaps that no one knew existed yet. Both help our local community, the EMC code community and the open source community. Some of our group has traveled to other cities to tell the PacLabs story, to encourage others to start their own coding cultures. For me, PacLabs has started bleeding into my other initiatives. My 6 year old son came to me with a “need” to build a robot. The first model was a cheap kit I found online that he named “Walks Funny”. Afterwards, he came to me with a list of improvements we had to make to his robot to make it walk less funny and to prevent it from falling over. After browsing around, one of the robot kits I found to build to was Roby. I chose this robot as an option because “it runs on Rasberry Pi, I’ve got experience with that from the Innovator’s Symposium.” This robot is such a compelling story I took it a step further and proposed that it be used as an educational pilot for our evolution of Scott’s school outreach program. Perhaps we give a classroom a robot they can code iteratively against instead of handing out swag. That idea has evolved into designing, building and coding our own “West Division SE Transformation Robot” that we take to schools and share with others. Epic… we created the start of a robotnado.

Phase 5: Customer Deliverables. I have personally been involved in 2 big, competitive deals this year that were booked based on the coding efforts of one of our high performing PacLabs members. I have at least 2 more deals in the pipeline that involve code work. These tiny open source apps that add features for our customers are huge difference makers. When I asked the team member that helped me on the latest deal about his background, he told me he started coding for the first Innovator’s Symposium in June of 2014. Less than a year later, his work is the basis for a huge deal. The sales team is starting to take notice and support us. Before, there were snide comments about beer in the conference room at 2:30. Now more people are sneaking in to check out what is happening. It’s awesome!

Phase 6: Product Improvement. This one is currently an unrealized dream. The idea is to take the rock stars that have evolved through the phases and designate a portion of their time to R&D. They would take a product with the idea of making it more accessible/easier for our customers to consume. If our products are the best on the market, we support a culture of openness AND are the easiest to consume… why choose anyone else?

I have seen the first 5 phases in action. They work. This team has accomplished incredible feats in less than a year. You can too. Get curious about this stuff, grab a few friends and take them with you. We are all here to help and we are rooting for you.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.