Ownership. It means, “I’ve got this.” It’s the words, actions, and attitude. It’s the competence and the confidence. It’s not associated with any particular job title or level. When it’s there, we feel good. When it’s not, we’re lost.

In the world of information technology, ownership can be elusive. Development blames operations. Operations blames development. The business blames IT. IT blames the vendor. The vendor blames the other vendor.

People suffer. At the end of the day, all we want is for someone, anyone, to take ownership. Is that too much to ask? Someone, anyone, please stand up and say, “I’ve got this. I’ll figure it out. I know what to do. You can count on me.”

In the IT industry, we’ve worked on this issue by creating specific roles with clear accountability. In the product model, we have Product Owners. In ITIL, we have Service Owners and Application Owners. In the world of data governance, we have Data Owners. I hear terms like Platform Owner and Technology Owner tossed around from time to time.

This is a partial solution. But in some ways, this is more of a symptom than a solution. Why do we need these new ownership roles? Because no one takes ownership. Do these owners solve everything? Well, not always. In many cases, these roles are executed within a very narrow scope of responsibility.

My story

Long before I had any sort of leadership title, I was an engineer. The company I worked for brought in a new technology platform called Citrix and needed to assign it to an engineer to learn and run it. I knew nothing about Citrix, but I was eager for something to call my own, so I stuck my hand up high.

I learned as much as I could. I took classes, joined online forums, and participated in the global Citrix community.

My goals initially were pretty straightforward. I needed to host applications on the platform, keep it running, and keep the business sponsors happy.

That didn’t take very long. From there, my ambitions grew.

I turned it into a shared service, finding new opportunities to host applications on the platform from different business units. That was fun, but it created a whole bunch more challenges. I had multiple stakeholders to manage. I also needed to find a way to share the cost of the platform.

I was just an engineer, but I became curious about the cost of the service. I developed a consumption-based charge-back model to fairly allocate the cost based on metrics that drove my costs. I developed reporting that showed the consumption behavior, so my customers knew what went into their costs.

After a while, the platform became a critical dependency for global business, so I made the service disaster-resilient and paid attention to our performance and uptime.

Lastly, I partnered with another engineer on the team to bring virtualization to the platform back in the very early days of VMware. The technology innovation was interesting, but it was the cost-effectiveness of it, that made me pursue it. We had some goals that weren’t financially viable in the traditional model, but this tech innovation made it possible.

So what?

That’s enough of a trip down memory lane. Here’s the point. While that story spanned several years, the entire time, I had the job title of “Systems Engineer.” Not Product Owner. Not Sr. Manager. Not IT Director. I wasn’t a people leader. I had no formal budget responsibility.

We all have an opportunity to own the full experience of our technology product. For me, it started with the core engineering responsibilities and naturally grew from there. No one told me to do it. It all materialized from a focus on my customers. I never really focused on what bounds I was supposed to stay within as an engineer. I just did what was needed.

Building ownership

Ownership may seem like something you either have or you don’t, but like anything else, you can develop it. We all have a starting point, and it grows from there. I’m going to retrace my steps once again, but this time as a series of questions I asked myself. These are the questions that developed my full ownership.

What do my customers need from me? They need a platform that runs their applications. They need me to fix it when it breaks. They need me to change it when they ask me to.

What happens when the technology gets old? My customers need me to keep it refreshed and updated with the latest and greatest hardware and software. They need me to do those upgrades in the least disruptive way possible while taking advantage of new features and functionality.

What about security? My customers use this platform for critical processes. They need their data and their identities protected as well as possible.

What happens to the business if my platform goes down hard in a worst-case scenario? I better build a design that’s disaster resilient and test it.

Who else could benefit from this platform? I bet I can earn the trust of other groups that will use my platform.

How much does it cost to run this thing? What business value does it provide? Is there anything I can do to make it more efficient?

What data do I need to provide my customers so they can manage their consumption and their costs?

How is the platform performing? How fast is fast enough?

How are others around the globe solving the problems I face? Have I managed to figure out some common problems that others face? If so, can I contribute to the community?

Your turn

Did you get a sense of the progressive nature of the questions? Do you see how I started with my customer, and then got more comprehensive in my approach? Did you notice how each question drove me to find the answer? I never thought for a second, “This isn’t my job.” My job was to satisfy the stated and anticipated needs of my customers.

You may be thinking I’m special, but I’m not. I was just a regular engineer. I had no aspirations of becoming a tech executive one day. I wasn’t on a management fast track. I just took ownership of my technology platform and served my customers. That’s it.

You may be wondering why I had to do this as an engineer and are wondering why my manager didn’t do this for me. Well, my manager had a huge portfolio of technologies, and I only had a few. Also, what I described was normal. My peer engineers ran their technology platforms just as well as I did.

Why?

So, all of this happened many years ago. Why am I writing about this today? I think we’ve somehow forgotten how to do this. We’re all very specialized. We play our specific role. We hope everyone else plays their specific role, especially those with “owner” or “manager” in their job title. Sometimes, that works really well, but often there are gaps. Who feels the impact of those gaps? Customers. Who stands in the gap? Owners.

Be an owner

I’d be remiss if I didn’t offer one more suggestion to all of you. If you are the reading type, I have a book recommendation for you. Read Extreme Ownership by Jocko Willink and Leif Babin. It’ll kick your butt.

Ownership may be in short supply, but it doesn’t have to be. This is your career. This is your job. These are your customers. This is your tech platform. Own it.

Podcast: Play in new window | Download