Next week, I’m headed to London to enjoy the balmy British weather, indulge in more than my fair share of fried food, and maybe even watch some cricket…the game on which baseball is based. Yup, I went there.   That sounds like fun, but the main reason I am going is because I have been asked to host a session at IP Expo Europe on Lithium’s transformation to DevOps. Prepping for my talk has been an interesting process, as it has prompted me (and the team) to take a step back and think about how far we’ve come in our transition, what prompted us to do this in the first place, why we’re doing it, and what – in hindsight – we would have done differently.     As far as why, it all comes down to speed right? I believe in synchronicity and that that multiple folks have the same idea at the same time. The one who succeeds is the one who is able to execute better and faster. It may sound overly simplistic but speed as a competitive differentiator is going to continue to grow even more important… the ability to iterate swiftly and focus on the right areas that will deliver the most value to the customer. DevOps is a key enabler in helping R&D teams go faster and execute better. There is strong data that is available that shows that companies leveraging DevOps are much more likely to succeed.   Our shift to DevOps has not been easy and there is a lot more to be done, but I’m proud of how far we’ve come. A few years ago, we were a very traditional engineering organization. Operations owned maintenance and we had some big silos and there was growing frustration about not being able to go faster. We were early in the industry to start moving towards Hybrid Cloud and  DevOps . But by embracing  DevOps , we are now seeing increased collaboration across the organization and it has put us in a much better position to move faster and more efficiently.   With big transformations like this, it is never smooth sailing. I’ve personally learned a few things like how hard it is to transition large applications, needing to balance the need to be prescriptive vs giving teams independence, and the importance of not trying to “boil the ocean” and do too much at once when you have a big vision.    I will report back after the conference on how everything went. If there is anything you think I should call out specifically in the session feel free to leave a suggestion in the comments.   Want more info on my session at IP Expo? Click here.   ... View more

I recall a time when my role as an engineer was defined so narrowly that my job description consisted solely of delivering on requirements from the product manager within the technical framework that the architect provided. I wasn’t expected to know what happened before or after anything that lay outside my purview. QA was handled by another team and there was a wall between us. Production operations seemed worlds away.   Ask any engineer and they’ll tell you that for the most part we still work in silos. After all, we are hired for our specific expertise and we focus on our part of the project. But not enough of us have visibility into the end-to-end context and process — from understanding the customer and the problem they are trying to solve, all the way to how the applications are run and maintained in production. Yet, having this end-to-end (e2e) understanding is critical to creating market-leading applications that actually delight customers.   Engineers with e2e knowledge are rare and highly sought after. I was trying to fill an engineering position on my team and talked with many great candidates. They provided examples of how to architect for high availability and how to build quality in. But when I asked them broader questions around topics like customer success metrics, availability targets for apps and what they achieved in the last three months, they stumbled. Why did this matter to me? Because engineers who have an e2e mindset and understanding get the full picture of how their piece of the puzzle impacts the whole system. Engineers that have e2e understanding are highly valuable because they bring with them the understanding that helps avoid incorrect assumptions that can waste time and increase costs.   Now, it’s true that the siloes between engineering and ops have started to dissolve as devops models become more commonplace, but in many cases especially in larger companies, they still exist. Additionally, engineers are typically insulated from any direct engagement with customers, due to a misguided belief that feedback needs to be carefully distilled before it is given to them.   So, how can you ensure that your engineers have solid e2e understanding? A lot of it can be accomplished by simply removing the siloes and making sure they are getting direct, unfiltered input:   1. Have your engineers be part of the initial concept and ideation process where they are directly engaging with customers and end users. This understanding will be invaluable as they design the system.   The best product ideas don’t come from those with the highest IQ, they come from the people who understand the user, their objectives and issues the best. This requires everyone to be intimately familiar with the users of the application and their context.  Make sure that each project has beta/lighthouse customers who are actively engaged from the ideation phase.    2. Embrace dev ops. Engineers who own production uptime will design and implement more resilient solutions.   Devops is not a team. Devops is a mindset, it is a new way to work where the engineering team and the operations team work as one to build the most resilient highly available systems quickly. Engineers who own uptime for their application and are on call when there are issues will invariably design and build highly resilient systems from day one.   3. Include e2e metrics such as customer adoption and uptime targets in your team and individual goals.   Make sure that engineering teams have goals not just tied to the release of their product but tied to the overall success of the product. Is it doing well in production with no quality or uptime issues? Was the product well received by customers, are they using it and giving positive feedback? Make sure that the team views these as their ultimate success metrics.   4. Make sure the entire team understands your deployment architecture and production set-up.   It is no longer good enough if there is only 1 or 2 people on your team who understand how everything works e2e in production. You need to ensure that your entire team is aware. With knowledge, better decisions get made. When engineers know your production environment better, they will make better design and coding decisions to ensure better quality, scalability and resiliency.   Developing an e2e mindset in engineers is crucial to the success of your production process. It’s also valuable to your customer. Engineers who design with a clear view of what the customer needs and wants will be able to delight them with the final product, and keep their companies on the cutting edge.   A version of this article originally appeared on Medium.  ... View more