Comment by memset | Hacker News Reader

Comment by memset | Hacker News Reader

Parent Full thread

This is huge. I have worked at startups where employees feels animosity towards the dev team. "What do they even do?" people ask, given we roll in at 11am and don't ever seem to fix any of the things that are broken for them.

Of course we are always saying "no" to every passing request - last thing we need is scope creep and to take on more tasks than we can reasonably accomplish. Of course we think we're busy, and we are, but we can't satisfy everyone. There is tons of appeal in just buying some software to "get the job done."

And we are so averse to buying third-party Enterprise Software Packages because they're, uh, bad, or something. Expensive. They integrate with Excel, and we hate Excel. We can do the same thing ourselves, obviously, but more quickly. Who needs an accounting software anyway, how hard could it be?

Often they are bad. Netsuite integration is awful, Salesforce integration is awful, and even startups who should theoretically have a superior product end up being awful (for example, last I checked, OrderGroove - which claims to take the pain out of subscription services - is not PCI even compliant, so they can't meaningfully handle billing issues.)

On the one hand, I want to applaud this - if you need something done, go buy something to accomplish the task and don't worry about your persnickety developers.

On the other hand, devs are often the ones who have to maintain and integrate with a half-baked piece of software and are never consulted to evaluate how viable that software will be to solve the problem at hand. But this trend makes me nervous, as an in-house dev, and I think that is a good thing.

> I have worked at startups where employees feels animosity towards the dev team. "What do they even do?" people ask, given we roll in at 11am and don't ever seem to fix any of the things that are broken for them.

This is fairly common, although I would extend it to include all technical departments (IT / Engineering). Ironically, I've also witnessed engineering beefing with IT & Helpdesk for this very reason.

> Of course we are always saying "no" to every passing request

All too often internal technical departments are viewed, rightly or wrongly, as units whose sole function is introducing speed bumps. I also tend to agree that the implications are potentially non trivial.

While my reply may only tangentially be related to TFA, your last sentence reminds me of the Manager / Career Tools podcast episode addressing this very issue: http://www.manager-tools.com/2012/02/internal-support-roles-...

From the podcast episode's description:

The relationship between internal support providers and their customers has to be one of the most frustrating in the corporate world. The provider NEEDS x and y and z before he can solve the customer’s problem. The customer just wants a thing, that does ‘you know’, and just works. Both are hampered by corporate policies and processes.

There are ways of making this relationship go more smoothly. But as an internal support provider you will need to change your perspective in order to make this work. You might find this hard to hear, to take and to make the changes we recommend. We’re dedicating this cast to the Atlanta January 2012 conference attendees who found it hard to hear, but thanked us for telling them anyway. We hope you’ll feel the same way.

I'm sorry, but by the end of that podcast I was fully willing to go get myself a life sentence for doing something horrible to the presenters. They made two main points:

1. You, as a member of internal IT, are subservient to marketing. Suck their dicks! "You're collaborating, but make no mistake, you're not a partner." (Also, the CEO will "piss on" the CIO whenever he gets a chance.)

2. Internal software development must obviously be "fungible", because it's a thing businesses do, and all the other things that businesses do are. Since every other department spends marginal amounts of ingenuity (and lots of bureaucracy) to do reliable, repeatable things, and managers can "crack the whip" to remove some of the slack+busywork+bureaucracy from their processes, then software engineering (a process of spending one's entire budget of ingenuity each day to create things that have never existed, and for which there is no precedent) must obviously be amenable to the same demands to "work smarter, not harder." And he says this while namedropping the Mythical Man Month.

I don't know about you, but the only thing I want to do in relation to these sorts of companies, is to out-compete them and obviate their markets in the long run, by keeping all my employees healthy and sane instead of "pushing" them to death for no marginal gains. This sort of attitude is precisely why "developing for the Enterprise" doesn't catch on as a trend among startups, no matter how profitable it is.

---

P.S.: They also begin to make the [sensible!] point that you should probably ask people "what do you need" instead of saying "send me your requirements" and then stonewalling, but it doesn't quite get there. That's obviously the reason you linked it, but it falls flat.

Here, I'll make the point they should have made, and I'll do it in one paragraph:

> Since your whole training in programming is basically a course in "teasing out the specifics of what people want in concrete machine-encodable business-domain terms", the fastest way to get those requirements out of people (who have not been trained in that) is to present yourself as a REPL, not a compiler. Imagine if you had to throw code over a wall and wait a few days to see it get rejected with an obscure compiler error (basically, imagine the 1970s.) Now imagine sitting down with the computer and just trying things and seeing what works. For the sake of everyone's sanity, you want to present yourself as the second kind of system. Otherwise, "buy" becomes a much more pleasant notion than "build", and as a CIO that should make you feel like you're not doing your job.

Thanks for your feedback. The podcast overall is definitely non-maker-centric and I guess it's been a while since I listened to both of the episodes, (parts 1 and 2 that is) or I would have added that it gets better in the second part. Perhaps you didn't have a chance to listen to part 2? (http://www.manager-tools.com/2012/02/internal-support-roles-...)

I would also agree with your summary, and add to it the presenters' proposition that improving your relationships with others in the organization will go a long way toward helping both them and you produce better results.

I had assumed that the devs in a start-up worked primarily on code for external customers and nothing - or practically nothing - for the internal customers.

I guess it depends what kind of start-up.

Reply on news.ycombinator.com