DevOps is dead — Let’s be DevProds

We’ve seen the move from a programmer plus operations culture to the emergence of the DevOps culture. The start-up movement, where small teams rule, the emergence of tools that allow developers to set-up complex infrastructures easily, others that allow developers to create powerful automation and configuration scripts and the recognition that small, empowered teams can accomplish great things, were all factors that brought together the IDE (or Vim ☺) and the shell, and let developers expand their reach. The DevOps culture had risen, creating a lot of opportunities for these newly created unicorns.

This small step was great and brought a lot of flexibility and power to teams. Combined with cheap and easy to set up cloud services, actual miracles happened.

DevOps is Dead. Long live DevOps.

So now it’s 2015. We’re happy, we’ve settled, we’ve accomplished a lot and we should congratulate ourselves.

DevOps worked.

So let’s move on. Let’s kill DevOps.

Let’s create DevProds.

DevProds are developers who believe their work extends far beyond the lines of code. When their work is in the hands of actual users, it’s only getting started. Actually, forget about “users”. Their products end up in the hands of people like you and me, but they also end up getting to people like our parents, our young cousins, our older friends, our friends who “hate computers”, our sister who has a smartphone on her hands 24/7, but couldn’t code to save her life.

DevProds know this and they’re not settling for less. They don’t just code for the backend, they’re not just writing APIs or libraries that “no-one will ever see”. They know they’re doing what they’re doing to make an impact. They’ll leave a mark.

Meet the DevProds

So, are you a DevProd? I’ve written a quick guide to help you figure that out.

You’re Product-focused

You know your product inside and out. You know why your team decided to build that feature and why that other one is sitting on the bottom of the Backlog. You understand why that component needs to scale and the other will never be a bottleneck. You know what your next priorities are, when users are leaving and why, how many are staying, whether they’re engaging with your platform like you’d like them to, what’s their lifetime value, what you need to do to increase it.

You understand requirements / Stories / Flows

You understand your customers needs, you know the hypotheses on the table, you want your product to succeed. You want it so hard, it itches. So it’s not a big deal. You can put yourself in your customers’ shoes and translate their pains to technical requirements, User Stories, UI Flows and even paper prototypes. You can look at them and understand how they affect the bits and bytes, the gear wheels, the code you write. You know what could demand a graph search, a NoSQL or a column-store database, a message queue or an API that can be easily extended to encompass what your product might need next.

You need Continuous Deployment

You are a DevOp at heart, or at least you know why you need Ops. You need them to maximise satisfaction for the people using your product. To make sure that happens, you have to put quality into everything you do. You need the assurance that if you find something’s wrong, you can fix it one minute and have it in your users’ hands the next. You need continuous deployment. Not because everyone else is doing it, but because that’s the only way everyone will be committed toward the same goal and your users will always be experiencing the excellence you want them to have.

Analytics

You know your work begins when the first person meets and greets it. You are analytics-driven because you know you’re not always right. Beautiful code is a means to an end. There’s always something to improve. Your users will tell you what it is. If it’s not them, it’s your infrastructure, or the business process you’re working to improve. And when they do speak to you and whether they make your analytics whisper or scream, you’ll be listening.

You’re not full-stack, you’re full cycle

You recognise that your purpose can only be truly fulfilled if you understand the pains of your users and how you can help. So you’re willing to be there. You would do support, you would talk to potential customers, you would lead the definition of new requirements, you would push yourself and your team to do better. In fact, you do!

You’re not just a developer. They can’t put you in a box. You don’t have to know everything, so you can’t be full-stack. But you can be there for the whole cycle and make it count!

Create a DevProd culture

So now it’s up to you, your company, your team, to implement a DevProds culture. This means you can’t just relay the responsibility to that guy who didn’t do what he was told in the last Sprint Plan, that manager who didn’t explain the requirement in excruciating detail, or that UX designer who handed you the latest prototypes. They have responsibility, yet somehow, so do you. You guys are one, you‘re A Team (or A Tribe, or even A-Team), and to do that you will have to become a DevProd.

You’ll raise hypotheses and carry them out. You’ll review analytics and bring the conclusions to your team. You’ll talk to your customers. You’ll sell your product when you can and you’ll do support (please watch this). You’ll want transparency because that’s the only way everyone is on the same page. You’ll want office happiness because you want everyone to be engaged. There can be leaders, there’ll still be guys carrying the vision.

But you will all be building the same product.

So from one Developer to another:

Be a DevProd.

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.

To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!