Fight The System: Battling Bureaucracy

25 min read
Business, Workflow, Clients, Teams
Share on Twitter, LinkedIn

About The Author

Paul is a leader in conversion rate optimisation and user experience design thinking. He has over 25 years experience working with clients such as Doctors … More about Paul ↬

Email Newsletter

Weekly tips on front-end & UX.
Trusted by 200,000+ folks.

No doubt, in-house teams face enormous challenges. However, overcoming these challenges by carefully handling internal stakeholders and your own department’s image is possible. Nurturing a website over the long term is a job that many in agency positions, including me, envy. If only you would overcome the bureaucracy. Find here techniques to help you lessen the load and start enjoying managing your website again.

If you work as part of an in-house Web team, you have my sympathy. If that in-house team is within a large organization, then doubly so. Being part of an in-house Web team sucks. Trust me, I know. I worked at IBM for three years and now spend most of my days working alongside battle-weary internal teams.

It’s hardly surprising that most in-house teams are worn down and depressed. They face almost insurmountable challenges:

Departmental feuds.
Too often, a website becomes a battleground for pre-existing departmental conflicts. Political power plays can manifest themselves in fights over home page real estate or conflicts over website ownership. After all, is the website an IT function or a marketing tool?
Uninformed decision-makers.
Rarely does an internal Web team have the authority to make final decisions on a website? Instead, decision-making happens higher up in the organization. Unfortunately, although these individuals have more authority, they do not have greater knowledge of the Web. Decision-making is often based more on personal opinion than the needs of users or business objectives.
Committees.
Committees are the curse of larger organizations. The bigger the organization, the more the number of people who want their say, and that leads to committees. Unfortunately, committees inevitably lead to compromise and design-on-the-fly. Both are the kiss of death to any Web project.
An inward perspective.
Becoming institutionalized is very easy in a large organization. Eventually, you speak an internal language and think in terms of organizational structure. This proves problematic when communicating to end-users. Not only do most large organizations have their own internal perspective of the world, some individuals even think departmentally, further aggravating the departmental conflict.
Endless scope creep.
When an in-house Web team is constantly available, calling on their help is easy. This is both a benefit and a curse. The truth is that many Web teams are taken for granted, and websites that should never exist are built and launched because there are no constraints. Worse still, good projects can be drowned as “internal clients” keep demanding additional functionality that the Web team cannot block.
Problem people.
The bigger the organization, the higher the chance they will hire a jerk. If you work for a large organization, I can pretty much guarantee you have someone in mind as you read this. These people can really hinder the work of the Web team and prevent a website from reaching its full potential.
Glacially slow progress.
With endless red tape and painful committees, getting stuff done in a large institution can be nearly impossible. It is not unusual for projects to grind to a halt entirely because they become dependent on other systems or projects yet to be implemented. I have even seen something as simple as the roll-out of a content management system take years to implement.

With the odds stacked so high against them, I am surprised in-house Web teams get anything done at all. Their success depends as much on their ability to navigate politics and bureaucracy as it does on their skills as designers and developers.

But do not despair. I can tell you from the over-subscription to workshops I have run on the subject that you are not alone. This is a universal problem and one that can be overcome, as I will outline in this post.

Our Web design agency specializes in complex projects. During my time there, I have developed certain techniques that will hopefully help others keep their Web projects moving.

Let’s look at four areas in particular:

Improving how your team is perceived within your organization,
Overcoming politics and problem people,
Ensuring that a project gets approval from the powers that be,
Delivering work within the scope and on time.

Let’s begin by addressing how Web teams are perceived.

Improving How Your Team Is Perceived

In too many organizations, the Web team is considered the lowest of the low. It looks like something straight out of The IT Crowd.

This is all the more bizarre, considering that websites themselves are perceived as being important. Somehow there is a disconnect between those who produce websites and the websites themselves.

This poor attitude toward Web teams boils down to two beliefs:

The Web team is a roadblock that needs to be detoured.
Many large organizations find themselves frustrated by their internal Web teams, seeing them as people who constantly block their more “imaginative” ideas and set restrictions on what they can and cannot do online.
Web team members are implementers, not experts.
Management perceives Web team members as “techies” there to implement the ideas of others. They are in no way perceived as experts who are capable of advising on strategy.

Fortunately, much can be done to overcome these beliefs. For a start, improve your communication skills.

Communicate Better

Most internal Web teams are terrible at selling themselves. If they were a Web agency, they would be out of business in a few weeks. Perhaps that is their reason for working in-house. But despite what you may think, most internal Web teams could desperately do with communicating and selling better.

To overcome the negative impressions people have of your team, you need to actively promote yourself and the work you do.

Here are just a few ideas to try:

Hold launch events.
When was the last time you celebrated the launch of a new feature or the redesign of your website? Holding a launch party is a great way to shout about your successes, and it’s fun, too. Email colleagues, telling them how excited you are about the completion of your latest project, and invite them to celebrate with you. Everyone loves free food, and it’s a great chance to show off your work.
Publish a monthly newsletter.
How will anybody know about the great work you do if you don’t tell them? One way to do this is through a monthly newsletter that features work you have been doing and cool stuff happening online. This is a great way to both increase your profile and educates people on the power of the Web.
Report successes to management.
Management needs to be regularly informed on traffic levels, dwell time, and conversion rates. If you don’t have any calls to action to track conversion, get some. If you have no way to measure success, then the team is simply a drain on resources. Demonstrate that you generate income rather than just spend it.
Offer training courses and workshops.
Part of your role as an in-house Web team should be to educate those in the organization about the Web. I’m talking not just about technical training on using the CMS, but rather more general training about the Web and how it can benefit your business. Sessions like this not only educate internal stakeholders but also increase your credibility and establish you as the expert.
Hold regular meetings with website stakeholders.
Set up regular meetings with those who most often use the website. Talk to people such as the head of marketing, sales, and IT. Meet with front-line staff who answer customer support queries or those who work with suppliers. These meetings build relationships across the organization and demonstrate that the Web team is always looking for ways to help the business.

By improving communication within your organization, you significantly improve the perceived value of your team.

Create Value

There can be little doubt that internal Web teams are undervalued. As an external consultant, if I say exactly the same thing to management as the Web team, management will listen to me and ignore its own people. This is largely because, as an external consultant, the cost of my advice is more evident. They listen to me because they are paying me in a very visible way.

Of course, they are paying as much (if not more) for their internal Web team. But that cost is not as evident and so is not valued as highly. The way to increase the value of your team is to make that cost more visible.

People are less likely to ignore your advice or waste your time if they are obviously paying for your advice or time. The way to establish this kind of value is to cross-charge for your work between departments. Have an internal charge-out rate based on salary, infrastructure, training, etc., and then price any new work coming into the department based on that rate.

This not only makes your value obvious, but it also makes “internal clients” think twice before asking you to build some ill-conceived project just because you’re “free.” Nothing will change perception more than making them pay for your time.

Of course, you might not be in a position to cross-charge. But that doesn’t mean you can’t go through the process of setting rates and costing projects. When you receive a request for work, respond with a breakdown of tasks, how long it will take and how much it will cost the company based on your charge-out rate.

While not as compelling as charging for work, it still drives home the point that your time is valuable. It might also make them think twice before suggesting a project, especially if they know that pricing will be included in your report to management.

Finally, keep track of the time you actually spend on projects. This will help with scope creep (see below) and show management how efficient you are.

Of course, cross-charging can be perceived as another blocking tactic, reinforcing people’s negative opinions of your team. Therefore, balance this with a positive and helpful approach…

Be Positive

No offense, but most of the in-house Web professionals I meet are a miserable lot. Okay, that was probably offensive. Still, it shouldn’t come as a surprise. With so much negativity aimed at Web teams, some of it is bound to rub off on them. It is up to you to keep the website on the course, and that involves telling people “No” or putting constraints on what they can do. The problem is that this damages relationships and eventually forces people to bypass you, often by outsourcing to agencies such as mine!

However, you don’t need to say no to people or even constrain them with rules. Take my situation, for example. When clients pay me, I don’t have the luxury of saying no. I have to be Mr. Positive, or they’ll just find someone else.

The next time someone asks you to implement a stupid idea on the website, try to be positive. Praise positive aspects of the idea (if there are any), and encourage the “client” to explain their thinking behind the rest. Often you will find something workable in the idea.

Even when the idea has no redeeming feature, there is still no need for you to say no. Instead, explain the probable consequences of the idea to the client, and guide them to the point that they reject it themselves. The problem with “No” is that it is a dead-end. It leads only to confrontation. By focusing on the positive and educating the client on the consequences of their suggestion, you create an open and honest conversation.

The process of educating the client on the potential pitfalls of their suggestion also demonstrates your expertise…

Become the Expert

The ultimate aim of improving your reputation is to establish yourself as an expert. If people see you in that way, then they will listen to your opinions and follow your advice. But if your reputation is already damaged, coming to be seen as an expert is hard.

One way to be perceived as an expert is by association. This comes in two forms: referring to another expert or having an expert refer to you.

Referring to an expert is easy. If you have no credibility in the eyes of internal stakeholders, borrow the credibility of others. For example, the next time a client asks you to put all content above the fold, don’t just tut and say that it’s a stupid idea. Instead, refer to a study on the subject, such as one of the several by Jacob Nielsen. This lends weight to your argument and demonstrates that you are well-read on the subject.

The second approach is to get an expert to back you up. Essentially, this is the very reason why I am hired by many Web teams. I am brought in to reinforce the arguments they have been making all along. Because I am perceived as an expert and support what the Web team says, I add creditability to the team and increase their expertise in the eyes of management. It’s ridiculous, but it works.

Finally, don’t try too hard. A true expert demonstrates their knowledge but is not afraid to admit their limitations. They are confident enough to challenge wrong thinking but not arrogant or aggressive. I speak with too many in-house Web developers who come across as sneering and condescending because they believe they are above everyone else.

While improving your reputation will go a long way to pushing your projects forward, it is not the only hurdle to overcome. No matter how respected you are, there will always be those with agendas that interfere with the smooth running of your website…

Overcoming Politics And Problem People

Politics are unavoidable in large organizations, and yet most of us consider ourselves above them. We claim not to play politics, and we moan about those who we perceive do. But in reality, we all do it. We all have an agenda and want our point of view to be taken seriously. To believe otherwise is naive.

Ultimately, having a holier-than-thou attitude to internal politics is damaging. If you refuse to deal with those who play politics and avoid pushing your own agenda, you will only damage the website.

To get things done in a large organization, don’t shy away from playing the political game. As the saying goes, if you can’t beat ’em, join ’em.

While we’re citing aphorisms, another one is keep your friends close…

… But Your Enemies Closer

One of the biggest mistakes people make with problem people is avoiding them. A far better strategy is to keep them close. The problem with avoiding your “enemies” is that you are entrenching their position. If they know you are hostile towards them (and trust me, they’ll know), then they’ll become even more hostile towards you. Eventually, the arms race of hostility will get out of control.

A better approach is to keep talking. Meet with them regularly. Ask them what they want from the website? Look for ways to build bridges. Listen to what they say.

Some individuals only want their voices to be heard. As long as you listen and make them feel important, they’ll go away happy. Also, let them win whenever possible. It may dent your pride, but that is a small price to pay for winning the war.

On the topic of war…

Avoid Confrontation

When I suggest that you meet with problem people regularly, I’m not setting the scene for a monthly showdown. In fact, avoid confrontation whenever possible, especially when other people are around. No one wants to lose face in front of their peers, which is why people become entrenched in their views in group settings.

Instead, use the tactics I spoke of in relation to being positive. Use the question “Why” as a way to encourage people to think through their position. Encourage positive contributions with praise, and explain their consequences in the gentlest language possible.

Finally, when you are criticized in a group setting (such as a committee meeting or group email), take a long deep breath before deciding whether to respond.

In my experience, there is little point in becoming defensive or, worse, retaliating. Most of the time, I don’t say anything at all. It’s amazing how often someone else will leap to your defense if given a chance. Better that they say how great you are than saying so yourself!

Of course, it should never come to that, especially if you learn to empathize with problem people…

Learn to Empathize

As Web professionals, we pride ourselves on our ability to empathize. We go to great lengths to get into the heads of our users and understand what they want to achieve and how to motivate them. We have become experts at nudging users towards the goals we want them to complete.

Interesting, then, that we totally fail to demonstrate this ability with our colleagues. Instead, we often dismiss them as stupid or “not getting it.” This kind of narrow-minded attitude causes many of the problems we encounter. Take the time to really understand your colleagues. What makes them tick? What problems do they face in their jobs that the Web could solve? What pet subjects could we use to nudge them in the right direction?

If we tried to empathize with our colleagues and understand their psychology, we would find internal politics much less painful.

Ensuring Approval

When working for a large organization, you constantly require the approval of others to move anything forward. If you want a budget for a new Web project, you need to get senior management to buy in. When you conceive an approach for a new design, it needs to go through marketing and the brand police. Sooner or later, everything you want to do on the website needs approval.

This approval process is often a nightmare. But it doesn’t have to be. Understanding a little about human behavior (which you should already know) smoothens the way.

The first step is to identify key influencers.

Identify the Influencers

Every decision-making process has key influencers. Sometimes the influencer is obvious because only one individual gives approval. But it is usually more complex. Sometimes the person you are dealing with is not really the one with the power. In many cases, someone else is, someone with whom you have had no contact. When dealing with committees, you will also learn quickly that not all committee members are equal. Some are senior, while others are simply more dominant or aggressive. The trick is to identify the key influencers.

But don’t assume that the key influencers are always the loudest or most senior. Sometimes it is those with the most connections or a close relationship with an executive. Identifying who can swing the decision in your favor can be tricky but is incredibly important.

Once you have identified them, the next step is to get them on board. This means dealing with them directly rather than wasting your breath arguing in a committee…

Avoid Committees, Talk to Individuals

The committee is the scourge of larger organizations. They stifle anything but the most conservative of ideas, they move slowly, and they undermine decisive action. Unfortunately, committees are here to stay, and there is little point to fighting them. But there is more than one way to skin a cat and more than one way to run a committee. In fact, you can use one of the committee’s greatest weaknesses to your advantage.

One reason committees are so slow is because getting everyone in a room to make a decision is hard. In our case, this is a good thing. Instead of meeting the committee as a group, start meeting its members individually. Some of these meetings can be over the phone or quick chats. But with the key influencers, take the time to sit down face to face and properly discuss the project.

Meeting with committee members individually has two advantages.

First, it puts you in control.

Losing control in a committee meeting is easy because members are changing your project on the fly. Design projects in particular suffer from this, with committee members making design changes as they will. But it happens in other types of projects, too.

Meeting with committee members individually prevents this, and you have the added advantage of being the only person with all the feedback and opinions. This puts you in control.

Secondly, it limits ego.

In meetings, people become conscious of their position in the group. Some dominate either because they are more senior or simply because they like to talk the most. Others feel the need to defend their corner in some departmental feud. Still others feel they have not had their say and walk away feeling frustrated. Meeting with people individually prevents this kind of group dynamic.

While avoiding committee meetings is hugely beneficial, I am not suggesting that you not include stakeholders in the project’s process. In fact, collaboration is essential to a project’s success.

Collaborate Rather Than Seek Approval

Shutting out others from the decision-making process is tempting. This is a huge mistake.

I am a big believer in collaborating with stakeholders and internal clients. By collaborating during a project, you change the dynamic of the relationships.

The problem with communicating with stakeholders only when you need their approval is that they feel no sense of ownership over the project. At best, they feel like an outside observer; at worse, they feel ignored. If you include them in the project as much as possible, then they feel engaged and have a sense of ownership. Then they are much less likely to reject project decisions.

Take the signing off of design concepts. Traditionally, this takes the form of a big presentation in which the design is shown to clients for the first time. This approach is flawed, because the client has not been involved in the production of that design. Consequently, they feel excluded from the process and disconnected from the design, leading them almost certainly to request changes in an attempt to regain control and feel engaged.

At our company, we take a different approach. We include the client in the process as much as possible. We discuss sources of inspiration, show them mood boards and sketch out wireframes with them. By the time they see the final design, they feel that it is as much theirs as ours. There are no surprises, and they are much less likely to reject it.

Taking them through this process has the added benefit of educating them about good design. This significantly improves the quality of any feedback they give. And getting the right kind of feedback is vital.

Control the Feedback

Whether you are showing stakeholders a design or asking for feedback on a proposed project, the way you handle responses is critical.

Again, design is a good example of this problem. Too often Web designers send out a design for approval via email with the question, “What do you think?” Never ask anyone “What do you think?” It frames the feedback in entirely the wrong way.

“What do you think?” focuses the reviewer on their personal opinion. It inevitably leads to feedback like, “I don’t like the color.” As any designer will tell you, comments like this are useless. Ultimately, it doesn’t matter whether the stakeholder dislikes the color, as long as the user likes it. Moreover, you have no insight into why the color might be a problem.

Whether you want sign-off on a design or approval for an element, direct stakeholders away from personal opinion and towards relevant questions like, “What will the user think?” or “Does this meet our business objectives?”

For sign-offs, I regularly ask stakeholders the following questions:

Does this design meet your business objectives?
Does the design reflect your brand and website identity?
Does the design align with the mood boards we developed together?
Does the design reflect the wireframes we agreed upon?
Will this design appeal to our target audience?

This will go some of the way toward focusing stakeholders on the right issues. However, the odd individual will still come back with comments like, “Can you make the logo bigger?” or “Change the blue to pink.” With a little forethought, you can avoid this problem, too.

Focus on Problems, Not Solutions

Whenever we kick off a project with a client who has to sign off on work, we start by defining the role we would like them to play. Instinctively, people try to find solutions to the problems they perceive. Instead of explaining the problem, they make comments like, “Can you change the blue to pink?” But this gives you no insight into the underlying problem they see, which means you cannot suggest an alternative or even better solution.

Encourage clients, then, to articulate the problem rather than the solution. Instead of making do with “Change the color to pink,” move them towards, “We’re worried our pre-teen target audience won’t like the color scheme.” Once you understand the problem, you can suggest alternatives, like adding unicorns or puppies!

The desire to suggest solutions is so strong that people quickly fall back into the bad habit. But because you have addressed this behavior up front, reminding them of it and asking what the underlying problem is becomes easy.

Another tactic is to constantly ask *why*. This question has two benefits. First, it gets people to articulate the underlying problem. Secondly, it gets people to really think through their thoughts rather than give gut reactions.

Gathering good feedback and focusing stakeholders on what matters are important components in the process of delivering a project. Even the most supportive of clients, though, can delay a project when you allow them to move the goal posts.

Delivering In Scope And On Time

In my experience of working and speaking with in-house teams, scope creep is a serious problem. What starts as a relatively simple project quickly escalates into something much more complex and not necessarily better.

This happens for several reasons. First, the higher the number of stakeholders who are consulted, the more new ideas and requirements are introduced. This is especially true when it comes to integration. Unsurprisingly, large organizations want their departments to speak to one another. But this too often leads to dependencies that slow projects down or halt them entirely.

The second reason is simply that the client cannot think of everything they need in advance. As they become increasingly involved in the project, they see more that can be done. This is understandable. Your internal clients will not be as experienced as you in working on Web projects and so cannot be expected to think of everything up front.

The final reason is that, from their perspective, the consequences of scope creep are minor. The client probably isn’t paying for your time and is not responsible for doing the work. They have nothing to lose from adding more complexity to the project.

You, on the other hand, have a lot to lose. Scope creep leads to delays, which makes resourcing for other projects nearly impossible. It also leads to overly complex websites that are hard to use and tricky to maintain.

You can use a number of techniques to limit scope creep without constantly saying no to stakeholders. The obvious one is to cross-charge. Clients are much less likely to request additional work if they know it will cost money. While this technique definitely works, it can appear a little callous and so should be used only as a last resort.

The best method is to establish a structure within which to work.

Work Within a Structure

Structure is useful for setting client expectations. It establishes boundaries up front that all parties have to work within. A key tool for setting boundaries is a statement of work. This document outlines all of the work to be completed and breaks down the tasks and timeframes. This is the blueprint for the project.

The benefit of this document is that it makes it clear from the outset what is within scope and what is not. The client will often fail to clearly communicate some aspect of the project, and this will get picked up if it has not appeared in the statement of work.

The statement of work also sets expectations for how the relationship will operate. It puts you in control and makes clear that the scope is fixed and cannot easily be changed. By outlining timeframes and milestones both for yourself and the client, you reduce the likelihood of slippages. But outlining timeframes and milestones in the statement of work is not enough. You also need to establish the consequences of not meeting these deadlines.

For example, many clients believe that if they deliver content three days late, then the project will slip only by three days. For you, though, this delay affects other work that you have scheduled to follow this project. It is important that they understand that, given your other commitments, even the smallest delay could push the project back weeks.

The same holds true for scope creep. Adding complexity delays the project’s completion and thus affects other projects. The problem is that exercising this discipline can make the client feel constrained and perceive you once again as the road block. So, wield this weapon carefully. I soften the blow by talking about phased development.

Talk About Phasing Development

The last thing you want to do is crush your client’s enthusiasm for a new idea they’ve come up with. As I said earlier, you want to remain upbeat and positive. Instead of pointing them to the statement of work to show that their idea is out of scope, enthuse with them about the idea. Discuss it together and outline roughly how it would work. But then point out that implementing it now would impede the project’s development, but that it could be implemented as part of a second phase.

You will find that most internal clients and stakeholders do not really grasp the dynamic aspects of the Web. They perceive the Web like print, that once the website goes live it cannot be changed. We know this is not the case; one of the huge benefits of the Web is that it can be changed incrementally.

Get the client to think about the Web project as being rolled out in phases. Launching everything together is unwise for two reasons. First, users do not respond well to sudden dramatic changes to a website (see the Facebook redesign as an example). Secondly, you can never be sure that the functionality they are proposing is what users really want. By rolling out a smaller website, you give users a better chance to interact with it and provide feedback on any functionality they feel is missing.

Finally, phased development limits complexity. With complexity comes a greater risk of something going wrong or the project being delayed. Phased development allows you to test more manageable components and so be confident in what you are delivering.

Conclusions

No doubt, in-house teams face enormous challenges. But hopefully, this post has demonstrated that overcoming these challenges by carefully handling internal stakeholders and your own department’s image is possible.

I am not claiming that what I have presented here is in any way a magic bullet. You will still meet individuals who refuse to cooperate or who throw their weight around. But by using these techniques, you should at least be able to lessen the load and start enjoying managing your website again. After all, nurturing a website over the long term is a job that many in agency positions, including me, envy. If only you would overcome the bureaucracy.