

Software to avoid the software people - sama
http://samaltman.posthaven.com/software-to-avoid-the-software-people

======
memset
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.

~~~
doktrin
> _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.

~~~
dmiladinov
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-...](http://www.manager-tools.com/2012/02/internal-support-roles-and-
responsibilities-part-1-0)

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._

~~~
derefr
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.

~~~
dmiladinov
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-...](http://www.manager-
tools.com/2012/02/internal-support-roles-and-responsibilities-part-2-0))

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.

------
steven777400
In large organizations, the shear overhead that is IT creates these barriers.
Developer tasks are often slated with plans one to three years long. IT fears
ad-hoc, one-off, slapped together, or anything like it because it becomes a
maintenance problem and takes special skills.

For example, in our organization, IT prohibits the use of Access to build
applications, because they end up being a versioning nightmare with copies all
over the place, and no concept of "source code".

End users end up building applications in Access because they can, and it will
take them two weeks to get a prototype. If they ask IT to do it, they'll need
a departmental budget (politics!) and it will take six months to get started
(between people who intentionally slow down process in order to look
important, and the filled up timeslots of developers). Then, it will be in the
standard IT development environment (for us, .NET and MS SQL) which means it
is opaque to the customer, and every change they ask must go through IT, and
gets bogged down in IT process.

So they go with Access. Two years later, that employee has moved on, and IT
gets a phone call from the customer "We have this mission-critical application
that has a bug and we need you to fix it!" and then the real pain starts.

------
orangethirty
This is new? I've been doing this for years. Its called _find the origin of
the pain_. You don't sell software to the IT team. You sell it to however
needs it. Pretty obvious. Just be nice to the IT team because they will be the
ones calling you when shit hits the fan. I like to send them small gifts in
the form of specialty food. Like cakes, and stuff like that. They always
appreciate it. Just don't send them pens...

------
onemorepassword
Web-based SaaS has made it much easier for corporate buyers to circumvent
internal IT altogether.

The shift in focus (if that is actually the case) probably has more to do with
wider acceptance and saturation of the tech-to-tech market.

How far this trend will go? Until internal IT for most companies except those
with very specialized needs has been reduced to maintaining desktops and a
network.

Edit: of course those desktops also risk getting replaced by BYOD...

------
nonamegiven
Can you sell me some software that will let me bypass my IT department that's
on "our" (I feel we have a relationship now) second ticket to fix a recurring
bluescreen because they insist on trying to troubleshoot it and fix it (see:
_second_ ticket) rather than just issuing a new laptop and troubleshooting it
on their own time?

------
olegp
Couldn't agree more! Consumerization of IT is part of the reason I started
<https://starthq.com>. I feel that there's a really big opportunity at the
intersection of internal IT, employees and third party developers.

------
dragonfax
I think he's missed the point of SaaS

------
OGC
14 lines is an article now?

~~~
nonamegiven
There should be more like that. Get in, say it, get out, STFU.

