mARTsketing: Disruptive Thinkers

mARTsketing: Disruptive Thinkers: We all know them, those types who just, can't, hold, it, in! You know, the people that go to meetings and to hell with the agenda, the...

Disruptive Thinkers

We all know them, those types who just, can't, hold, it, in!

You know, the people that go to meetings and to hell with the agenda, they've got something to say and they'll hijack the entire meeting to get their point across.

We have all worked with these people from time to time, heck I've BEEN that person from time to time! And as much as everyone groans when they see that So-and-so the loud mouth has been invited to a meeting, I'm here to tell you that these people can actually be incredibly useful, if you approach them in the right way.

I call them Disruptive Thinkers, they are usually very passionate about what they do, often quite knowledgeable, and best of all, are prepared to share their thoughts on what's not working and how it can be fixed. Their brains operate differently to other people's and the way they think about issues can be viewed as disruptive. For them challenging the status quo IS the status quo.

BUT you need to work with them in order to get the best out of the relationship.

Firstly you need a strong Chairperson, in any meeting with a Disruptive Thinker you can anticipate when they might want to take the floor, and thus prepared you can allocate time for this to happen and politely shut it down when it's gone on too long.

"Thanks for that, I appreciate your input, now if we could just hear from some others at the table", is one way to keep things in a box.

I often promise to take that discussion thread offline and meet up with the DT later on and then make sure I do.

Another tactic is to invite the DT to form a sub-committee so they and some others can work on his particular hobby horse.

One thing I have found from the DT's of this world is that when asked to contribute, the good ones will do so readily, almost always reading and providing feedback on documentation in a prompt fashion, be willing to brainstorm solutions and the like.

They also like being leveled with, you can say "This project is a bit of a shermozzle but the CEO is pushing it through before the end of Fin Year", they'll usually appreciate your candor and will modify their input accordingly and swing into "Lets get this thing sorted quick" mode. Because paradoxically DT's are actually good team players. 

The worst thing you can do with a DT is to sideline them because they are too much like hard work, that will only make them fester and spread their dissatisfaction more widely. It's much better to grit your teeth and engages them so they can walk around the office saying "This thing is terrible but Ricky and I are working on a solution." than have them say "This thing is terrible and no body listens to me, so it's only going to get worse.".

Anyway if you have any disruptive thinkers in your midst, I encourage you to seek them out, engages them, you'll find the rewards will be much greater than the effort.

Why the capital funding model can lead websites to mediocrity

I should point out that I am talking here about most large corporate, institutional and government websites, and I consider this to be a universal issue, I am not speaking about any specific workplace or project that I've been involved in, more bits and pieces of various web projects I have seen and witnessed, both successful and less successful ones over the years. I will however cite a successful project (if obliquely) that I worked on which was the opposite of the dominant paradigm and it's success is really the key factor in me forming this view.

And for sure, there are good examples out there that work within the dominant paradigm, but for many websites this process which I'll explain shortly really does limit what can be achieved.

So. Say you need a new website, somebody takes up the challenge and eventually convinces the powers that be, that this is the case and it becomes a 'capital works' project. Because it is considered that a website is an asset and that the cost of building a new one should sit outside of the normal operational accounts it sits in the capital works side of the ledger. 

So why doesn't this process work? By definition capital projects have a start and completion date. Thinking about a website through this prism is fundamentally flawed.

A website is never finished, a website is outdated the minute it gets launched.

A website is intangible. 

The environment they sit in is intangible. It is constantly being updated and improved.

By capitalizing a website, you create an environment whereby once every three to five years a major site gets built for a large sum of money and then as a reaction, the ongoing maintenance spend is usually kept to a minimum. 

Any request for say, for instance, to change the site significantly mid-way between cycles to say a mobile optimized site would usually be met with a "What? We've just spent $XXX on a site and now you want to change it already?".

Under a capitalized project model what can you say to this? Not much except to explain that online is a fast placed world etc, etc. while all the while suspecting that your Boss now thinks you are stupid for not foreseeing this 18 months ago. When really what needs to be said is "because we fund this thing likes it's bricks and mortar and it isn't".

So there's currency and lack of post-implementation development, there's also the extra layers of management, governance, project process and the like that go into a major capital works tender and project, this tends to force an element of project by committee. Again if you have committed a large one-off sum of money, people are going to want checks and balances in place, CEO's and other senior stakeholders will have opinions, blowing out the number of involved persons substantially. The ability to extract a clear and concise brief becomes challenging.

So what to do?

Firstly I would advise cutting all initial website capital development budgets by a third and then flow the other two thirds over the course of the next two years and not prescribe what those two thirds should be spent on because you don't know yet. I would hope that a case could be made to still keep this as a capital expense, in the sense it's not a one off 'build of a shed' but the building of a new shed every year. This may be difficult and if it can't be capitalized then so be it.

This is entirely possible because of open source. The days of websites being designed on proprietary software, in my opinion are well past. They are costly, they force changes and updates to wait for new version update from the developer and they tie you down to a supplier.

Secondly I would implement and empower a very small project team with very shallow lines of approval to deliver what they determine is best based on research, best practice and a clear focus on core audience and for them to do this ongoingly.

I was involved in a small skunkworks style web build once, we had three people involved at the client end, two at the project end and it was the best website I have ever delivered and what's more, by working with open source and doing so on a small budget we laid a platform down for a continuous improvement model.

And this is really it, spread the money across years rather than concentrate it into one defined project and empower a small team to deliver a continuous improvement model.

But here's the rub, why doesn't it happen this way? I mean I get why the web dev companies are compliant in this, they like winning big contracts and are happy to build what the client wants, of course from their point of view they'd want the big cheque AND the large ongoing maint budget. But when the end result is that almost no one ends up being completely satisfied with the outcomes and the ROI why does no one actively push another way? That rhetorical. Don't answer that unless you work with a web dev company, I suspect its that this model is so entrenched, that shifting the paradigm will require a long term culture change.

I'd be really interested to hear your tales of web builds and whether you agree with me that we need to find a new way to fund websites  or if it's just implementation that is poor and not the over arching structure.