instagram

Partner v. Tool

[Unsurprisingly, I’ve apparently chosen to make up for the tardiness of this post with verbosity. Good luck.]

Short version:

I think web teams that embrace genuine partnership rather than the traditional tool (service) model will have the most success going forward. In my experience, web teams generally start from a deficit when trying to become partners, but this can be overcome with properly focused proactive effort.

[Super-Extra-] Long version:

I had considered an alternate title for this post, Partner v. Service, but ‘service’ has too positive a connotation.

That doesn’t seem a terribly positive start.

It’s not, and I suppose that’s part of the point, but, in case I’m overstretching the case a bit, let me back up and explain what I mean by the two terms, as far as web design and development is concerned.

  • Partner
    An equal shareholder in the responsibility for the success and failure* of a given project, in the short and long terms.
  • Tool
    The service or functionality through which a project is executed.

In my experience, web design and development teams are almost exclusively tools. Yes, an element of the slang connotation is included therein, but just so we’re clear that I’m not pointing fingers willy-nilly, I’m on those teams which I’m identifying as tools.

Web dev & design as a tool
Historically**, web development has been considered a service which a client pays for, much like a craftsperson is paid to build a chair or a mechanic is paid to fix a car. In all these services, there is of course an element of partnership, because each provider is invested in the success of the end product to encourage future sales.

The distinction, however, is that the service provided by the craftsperson or mechanic is for a pre-defined item or issue. A chair is a chair and a car is a car. Certainly, things change in both fields, but these changes tend to be gradual. In any case, if a craftsperson cannot design the latest style of chair or a mechanic is not trained to fix a hybrid vehicle, the client simply goes to one who does. The service itself does not change.

The web is fundamentally different. The web is change. Contemporary consumers expect that web content will change. Unfortunately, many web projects are being approached with the traditional product/service mentality, though this is a two-sided failure.

On the one hand, clients, being human, are reluctant to change their ways. They are familiar with paying for a thing and getting the thing, and the getting of the thing means the end of the service (in this case, the project). Of course, service agreements and other things make this a bit of a simplification, but the same is true of traditional warranties and service plans. Even in these cases, though, the gray area is almost exclusively around maintaining/supporting the existing thing, rather than upgrading it to a new thing.

The other hand, though, is the more insidious. This is the web dev groups allowing themselves to be treated simply as tools used to create things.

I say ‘allowing themselves’, but it’s obviously more complex than that. Historical precedence, limited finances and limited resources all regularly play their part in reinforcing a view of web development as a tool, particularly for internal web dev groups which were often initially formed to serve a specific need (building the company’s web site, developing internal training software, etc.) under the belief that doing it internally would be cheaper than hiring it out***.

Whether the web dev teams are internal or external, though, these real-world limitations often keep them from being involved in projects as partners, by their own actions. It is a catch-22 of such a cut-throat business. The need for work often pushes these teams to fall back on the ‘easier’ and more familiar role of tool (or enabler, if we want to get a little psychological about it) in order to keep in business.

The obvious problem with this situation is that those teams are only digging themselves in.

As an example, when I introduce myself as ‘Bill’ to someone because

  1. I’m just starting out and not bothering with formalities,
  2. I want to show how easy I am to work with by giving my nickname, or
  3. C) it’s what most people have always called me,

then this new person will call me Bill. If I later want to be called William, however, the battle will always be uphill. My grandmother will never call me anything but Billy. My friends and past co-workers know me only as Bill and will likely assume they are meeting someone new or that I’m putting on airs if I insist on William.

New people, of course, won’t know one from the other. If I introduce myself as William, they will know me that way. Unfortunately, it is likely (particularly in our hyper-connected world) that they will run across other people who know me only as Bill, and the distinction of address will, at the very least, be cause for curiosity, if not a question of my motives in making the change.

Okay, I think I’ve run that example into the ground, but the point is valid for web teams, particularly those that have been around for a while and those that have grown from internal needs.

Retreating to the previous example one last time: Is William better or worse than Bill? That entirely depends on whom you ask and what the context is. This same fact is true for web teams and, I believe, becomes the crux of this issue:

Does the web team want to be a partner or is it happy performing as a tool?

Let me be clear that there is no inherent right or wrong here, no better or worse. A reliable tool can be a lifesaver, while an unmotivated partner can ruin the best intentions. The right match is obviously key.

However, I believe many (most?) web teams want to be partners rather than tools (again, I think this is even more pronounced for internal teams). Unfortunately, it often ends up like Sysiphus pushing the boulder up the hill, only to have it roll back down before he reaches the top.

Why is this?

I’ve already mentioned the commonly cited limitations like financial or resource constraints, but these are mainly external factors, things often beyond a teams’ control. For me, these are secondary problems to the real issue: Lack of influence.

It’s very hard for a hammer to build a house by itself. I can imagine it being possible, but I definitely wouldn’t want to live in that house, pay for it, or be responsible for its construction.

Similarly, it’s very hard for a team that has historically only executed the directives of others to be considered an equal partner in conceiving such directives. It’s not that the idea itself is ridiculous, but what proof do existing partners have that such a team can see the ‘bigger picture’ and provide valid, substantial and critical insight?****

Web teams need to provide more than the service they are executing. They need to be involved in the conversations that lead up to the request for that service. In effect, they need to start thinking less about having clients and more about working with partners.

That’s great, O Wise and Magical Oz, but how?

1 word: Pro-active.

Consider that everything I’ve talked about so far has been in reference to web teams handling requests, not creating those requests. Why? Because that’s how web teams have traditionally worked. A client comes to a team with a problem***** and the team finds a solution. Very rarely does a team identify a problem for a client.

Yet another analogy: Looking for a job.

The overwhelming majority of people look for work by searching job postings. This makes sense. If a company is looking to hire someone, the company makes the opening known and fields the potential candidates, whittling down to a final offer of employment.

But imagine for a moment that you are an employer. As far as you’re concerned, you’re business is doing well and you are not hiring. One day, someone contacts you to warn you of a potential problem or gap you were not aware of. Moreover, that person has the skills to address this issue. Are you now interested in that person (assuming, of course, that this is all above-board)?

This is where web teams can become partners. Don’t wait for work. Go find it. If an external shop, identify potential clients by reviewing their existing web presences and then show them how you could do something better.****** If an internal group, you should already know your clients well enough to propose solutions. If you don’t, get cracking.

In both cases, these web teams are now partners from the outset precisely because they started the conversation, and because they started it by demonstrating expertise and insight.

Easy? Actually, not as hard as it seems. It does mean having enough time outside of executing all the existing work, but, for example, there is certainly no shortage of poorly executed web sites in need of redress.

As a final thought (in case you’re not completely asleep), I see this problem coming into sharper focus right now, as the current web dev landscape is exploding with new site creation tools, ranging from more code-oriented (Drupal, Joomla, etc.) to more drag-and-drop (PageLines, SquareSpace, etc.) with a wide range in between (WordPress, Movable Type, etc.).

This means it’s now pretty easy for non-web folks to create some very professional-looking web sites, and that means tool-oriented web teams are being pushed out in the cold or forced to fight over smaller and smaller niches. There will always be space for specialized tool-oriented teams, but I think those teams that fully embrace partnership will be better off in the longer term. Such teams will be leveraging their expertise to help define the needs, wants and expectations of the requests from the beginning.

 

* Perhaps I’m pessimistic or have never worked for the right team, but I’ve never been part of a project that met or exceeded every single expectation (the reasonableness of said expectations is, sadly, irrelevant). There is always something that was missed or could have been done better. IMPORTANT: This is not a bad thing (and will be a topic for a future post).

** It’s always weird to me to use terms like ‘historically’ or ‘traditionally’ in reference to web development and design, given that the field is really only about 20 years old, with the vast majority of what we know today being in place for 10 or less. It’s a good thing to remember from time to time, though; helps avoid hubris.

*** which it often was, particularly in the wild early days when flat, boring 4-page HTML web sites could cost non-tech-savvy companies $25,000

**** Which, presumably, is what each of the existing partners already brings. If that’s not the case, then there are larger issues that need addressing.

***** Real or perceived, which is a different topic altogether.

****** Not just flashier, but genuinely better for the client’s business.

Web teams generally start from a deficit when trying to become partners.

2 Comments

Leave Your Reply

Your email address will not be published. Required fields are marked *

*

*