Once upon a time, many moons ago, I worked at a business where the web design group were frequently at odds with the customer service group. The customer service group would edit code on the live web server, breaking code all over the place; when they asked for changes, the web design group was in no hurry to help them. This is how I heard it, anyway, and I was in the web design group. I'm pretty sure that I'd have heard it a different way around if I'd been a Hatfield instead of a McCoy.
is you a Hatfield or a McCoy?
We had three help systems - a private system for the customer service people, a public set of help pages, and a half-public, half-private contextual help system, which provided content from the public set of help pages, but only content that was relevant to whichever page the user happened to be viewing or using at the time. In fact all systems viewed essentially the same content, which a publishing system formatted.
My job was to maintain this publishing system. The code was not good. It looked like a stoned engineer had written deliberately overcomplicated Perl, in an effort to passive-aggressively cordon off the indecipherable territory of his code, and that in fact is probably what happened. I met the guy who wrote it, and I'm pretty sure he was stoned during some of our conversations about it at work.
Anyway, conflict revolved around this system, and in the process of maintaining it and keeping it running, I began adding a few new features as well. Around that time, someone came to me. I didn't think of it this way at the time, but he basically wanted to turn this system into a fortress where he could hide our HTML from the customer service people. The customer service people wanted the text on the web to be accurate and up to the minute, whenever the site changed; this was in the days before CSS, so sometimes when they edited help text, they broke both the markup and the design in completely irretrievable ways, making the site look fundamentally unprofessional (and this was a site which saw a ton of business, in a financial field). But when the web design managers complained, the customer service group told them that having out-of-date text on the live Web looked unprofessional too.
I told my manager that I could do what he was asking, but in order to do it, I'd need to rewrite the convoluted Perl and turn it into something object-oriented. Being young and fairly naive, I wanted to turn it into object-oriented Perl. He told me "go ahead," and I set about building him his fortress.
I was new to objects, and of course the object-oriented Perl required a lot more manual lifting than languages like Python or Ruby - especially in the days before Moose - but it wasn't too long before I had the core of it redone in objects, and as I moved it from a legacy tangle to an OO system, I came to learn how it worked. You know this feeling if you've ever translated something messy into something clean and object-oriented; you discover the simplicity in the solution and end up with a much simpler design.
At this point, an idea occurred to me. I realized that the simpler design (which revolved around Pages and Templates) was simple enough that I could use it as a tiny web framework in a Perl CGI script, so I built a tiny app with it, dropped it into my home directory on one of the dev machines (we worked via Telnet, then, on external Solaris boxes) and told my manager to have a look. I suggested to my manager that we could use this simple web framework to set up a web interface for the customer service group, which they would massively prefer to making edits, since they didn't know how to use Unix well at all.
I know this joke is years out of date, but I was just reading about this campaign the other day
Soon, I added version control. This killed two birds with one stone. First, by building version control into the web interface, I could make it impossible for the customer service group to commit anything to version control without also writing a comment about it. Second, the existing publish path occurred on servers where the customer service group had logins, and version control was not installed. At a company doing a lot of business in finance, fiercely bearded sysadmins guarded their privileges as jealously as savage warlords guarding the only pass through a snowy mountain range. So the only way I could add version control was by moving the HTML in question out of hostile territory and onto the more traditional publish path for our group, which occurred on different servers controlled by different sysadmins who were equally bearded, but who had already given us access. (And, more to the point, who weren't about to give out access like jellybeans to any random customer service person who wandered onto their mountain.)
no, thou canst not hath root
I kept building new features, while turning down feature ideas that I didn't like, and after a few months, I'd built a CMS around my own simple web framework before I ever knew that either CMSes or web frameworks existed. The CMS defined a very specific workflow, with review for proposed changes, approval permissions, and a regular publishing schedule, all of which defined a process that made life better for everybody. I continued adding features, usually ones which benefitted my manager, but several for the customer service team as well, partly to be fair and partly because I wanted them to use it. Like Facebook bringing your social network to its advertisers, I was to some extent building something to draw one group of people in for the benefit of somebody else. As sinister as that sounds, the system satisfied both groups. The bickering continued a little, but it was half-hearted, mostly out of habit, and it died away quite soon.
Peace was restored, and summer was warm in the kingdom.
I brag that I solved this issue without managerial authority, but it's possible that having any managerial authority would have been a disadvantage. If I'd said to my co-workers, "Hi, I'm 23 years old, I'm going to design a new business process that makes sense, because you people don't know what you're doing," I'd probably have either gotten myself fired, or gotten myself into a large number of unpleasant conversations that would have all taken a very long time. But because I built a new system, it was easy for me to reshape the business process, because any time I heard an idea I thought was a bad idea, I would just lie and claim that it was impossible. It was likewise easy to say "but you could do this instead," and use the resulting feature discussion as a diplomatic negotiation between the two warring states.
This reminds me of a tweet which annoyed me:
A lot of other people liked it:
However, the contempt in this tweet strikes me as naïve. The win in the story I've just told was not due to my tech skills. The tech skills were absolutely necessary, but the win came from using feature discussions to find out how to redesign a business process. The discussions and the process made the real difference. Likewise, it's not necessarily easy to satisfy your users by rejecting every feature request which annoys you. Try it and see how they like it. The win there came from experience organizing and managing people on extra-curricular activities at my high school (and, actually, my church). I chose what to reject based on whether or not I thought it would help them get along.
Although great tech skills were involved - people afterwards began calling me a "Perl guru," and at the time I was young enough to believe it - it wouldn't have meant much without the so-called "soft skills" to back it up. So I totally disagree with this tweet. At that company, I earned an upper middle-class living combining soft skills and tech skills. Valorizing one type of skills and scorning another is less practical than acknowledging the usefulness of both.
Anyway, long story short, when people tell you the features they want, they tell you what it is they want to do; if what they want to do is dysfunctional, build something else.
Related: How A Great Web Team Fired Their Utterly Useless Manager
Stay tuned for the video.