I Am Not A Supplier

Based on yesterday's thoughts on No Estimates, the discussion rolls back around to how I see myself as a developer:

I am not a supplier.
I do not simply provide services.
I am part of the business.
I provide value that moves the business forward.

As a developer, my goals are the same as the business I work for. I want to see the company succeed. The way I do that is to make the business run easier, more smoothly, and economically through the software that I build.

I am just as much a part of the business as Marketing, Strategic Planning, Operations, Sales, HR, and Maintenance. My role as a developer moves the company forward just like every employee of the company.

But this is not necessarily how the company sees me.

Just a Supplier?
This is a topic that I've written about before, and my thoughts have been coalescing over the years. At a company that I worked for, there was a Vice President of I.T. who had a goal: he wanted to be asked about the color of the carpeting in the new building.

What does this have to do with I.T.? Absolutely nothing. And that's exactly the point. In the executive meetings, the VP of Marketing was asked these types of questions, even though it has nothing to do with marketing. The VP of HR was asked these types of questions, even though it has nothing to do with HR. These groups were seen as integral parts of the company.

The VP of I.T., however, was only asked questions that had to do with technology. And this is indicative of the overall issue: I.T. as a supplier rather than a part of the company.

Coding to Specification Only

Unfortunately, many software developers see themselves as suppliers. They are not interested in understanding the business but are perfectly happy to simply code to a specification that someone else gave them. I've never been successful working that way. Only by being part of the business (and understanding the goals and how it works on a day-to-day basis) have I provided significant value as a software developer.

Common Goals & Vested Interest
This attitude of "just a supplier" has led to some issues that many companies are just now realizing. And it really comes to light with the phenomenon of outsourcing.

When you think of I.T. as a supplier, then it makes perfect sense to outsource it. It's not part of our core business, so we can get it from somewhere else -- like a utility. But then the reality of the decisions set in.

When a group is outsourced, they no longer share the goals of your company. Let's take a look at a scenario: your company sells consumer products on-line. The primary sales time is Christmas season (with a huge influx of sales on Cyber Monday).

Scenario 1: Common Goals
When the I.T. department is part of the company, then there is a common goal: success of on-line sales. So if credit card processing goes down on Cyber Monday, it's an "all hands on deck" situation where everyone is troubleshooting the issue. The network team is checking connections to the card processor; the server team is making sure that that servers are not overloaded; the database team is making sure that transactions are being committed; and the development team is checking to see how the applications are handling the loads.

Everyone is working toward one thing: getting on-line sales back up. It's what we do. It's the whole purpose for being there.

Scenario 2: Disparate Goals
Let's run that situation again, but with an outsourced I.T. department. Now the goals are different. The goal of the company is still the success of on-line sales, but the goal of the outsource company is to fulfill the service level agreements (SLAs) that are in the contract. The success of the outsource company is not dependent on the success of your company.

So if credit card processing goes down, there are trouble tickets that are opened. The company is concerned about every minute of outage due to lost sales. But the outsource company is concerned about making sure they fulfill their contractual obligations. This probably does *not* result in an "all hands on deck" situation (because that would have made the cost of the contract too high to be practical).

Unfortunately, I have seen this happen. Before outsourcing, we had dozens of team members troubleshooting various issues. After outsourcing, there was a conference call with the account managers and very little actually gets done.

There Is No "Us" and "Them"
One reason that the company treats I.T. as a supplier is because that's how we often act. We don't even act like a cohesive team within I.T. For some reason, we (as technologists) don't like to be seen as the party at fault. It may just be a side-effect of the other traits that make us good at working with technology. We like to be seen as infallible problem-solvers.

This leads to an "us" and "them" attitude with other teams inside I.T. So when a user calls in an issue with an application, we might say, "The application is working fine, so it's not us. It might be the network or database that's having problems. I'll forward you to the network team."

But we need to look at things from the user's perspective. The user doesn't care what the exact problem is or who is responsible for it. All he knows is that the application is not working, and he cannot do his job.

We need to react to the users with this in mind. If someone calls in an issue with an application, we should say, "I can't find the problem in the parts that I can see. Let me work with some other members of our team to figure out what's going on." Then work with the networking or database teams to try to nail down the issue.

And after solving the issue, the proper response to the user is, "We fixed the issue, and we're working to make sure that it doesn't happen again. But be sure to let us know if you run into the same thing." The user does not need to know whether the problem was the application, the database, or the network. The user doesn't care. All he wants to hear is that "we" (the I.T. team) have things under control.

Forming a Partnership
I've written many times about forming a partnership with the business areas. And I have been most successful as a developer when I had a good understanding of what my users needed to do on a daily basis -- the steps they went through to do their jobs. When I understood this, I could automate the little things to make their jobs easier. And I could make suggestions on bigger things that could streamline processes.

I knew that I was successful at building these partnerships when our company was hit by a round of layoffs. Most departments took a 10% staff cut. The first thing that happened was that my users were calling me for help, "We just lost 40 hours of labor; can you help us automate this process that takes 8 hours a week? That will take off some of the strain as we re-distribute work and re-prioritize."

It was these partnerships that kept us all moving forward in the same direction.

Wrap Up
What does this have to do with No Estimates? It's really a first step. Last time, we talked about the trust that is required between the business and development teams. But what if we eliminate that line that divides these two concepts? What if instead of having "the business" and "the developers", it was all just "us" -- a group of people all working toward the same goal.

I don't think of myself as a supplier. I am part of the business. I add business value. And when the business moves forward, I move forward with it.

There are times that I wished I ruled the world. I would try to spread this attitude to all of the developers who think of themselves as suppliers. And I would try to spread this attitude to all of the companies that think of their I.T. departments as suppliers.

In this world, everyone would be working toward the same goals. I.T. teams would be a true part of the business and continually add value. And companies would be more successful.

These changes are made one person at a time. I hope that you join me in this quest.

Happy Coding!