Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I was a back channel route to engineering at a company I worked for a while. A few of the engineers trusted me and a couple select customers / sales guys knew they could come to me to run a bug by me 'in theory' and if we had enough information I could unofficially run it by engineering without going through the song and dance of the typical support channels.

I could get a quick ya or nay form them on some things and it was so much faster for everyone involved.

If it was a ya, I knew we had something, still more work to do but the case would skyrocket through the usual channels and engineering was engaged and ready.

If it was a nay, the usual channels it went and everyone was ok with that.

The engineers would give me a few minutes knowing I wasn't going to bring them poorly thought out garbage, I would limit the rate of these special situations, and special customers / sales guys could get the job done way faster.

It was a well known process by those who knew about it... but not everyone knew.



This exists in almost every company by design. Engineering teams wouldn't make any progress towards their mission if they are constantly dealing with outside interruptions, but at the same time there are things which should be qualified.

Customer support is a cost center and the focus is on mitigating the cost of providing that support. If you fail to do this you can burn through a lot of cash quickly. What management needs to realize is that this is also an important interface point which requires attention. This doesn't happen at all, or is inconsistent.

It's important for at least the following to happen:

1. Bad issues that engineering will fix don't get stuck in support.

2. Product management review and respond to feature requests, or enable support to respond to customers.

3. Support have a reasonable level of technical and communication skill, and are empowered to answer for the company.

4. The organization works through rather than around support.

What I've always found interesting, is that all of these are often failing in some way at the same time in an organization of any size.

Your role as the back channel is helping to provide some coherence here. However, things can go bad if you left. Inevitably, this is the fault of the company, but when I've found myself in this position I've tried to "promote" people in support to take the lead on this role. Further, formalizing the special request process to be minimally tracked helps visibility with my manager and others. Eventually managers ask why you have become a gopher.

Improving the workflow often involves helping support build relationships with engineering. Management can buy in if support attrition is high (it often is if there is a limited career ladder for support) and it can also improve their perception when people are focused on trimming support cost.


The binary distinction between "cost centers" and "profit centers" has always seemed arbitrary to me (especially since, as an engineer, I've been in both without my work being substantially different).

To be frank, it seems like an organizational way to say "we don't find this work to be valuable or interesting, and we'd like to do the bare minimum of it - in fact, we'd like to unleash smart people to explore new frontiers of just how minimal the bare minimum could possibly be."

It seems like this leads to incredibly predictable problems: brain drain, demoralized workers, the bare minimum being aimed for and not actually being achieved, etc.

I feel like a better organization has no "cost centers" - every single role at the company contributes to the mission and to the bottom line. If they didn't, that position wouldn't exist.

What am I missing?


There are parts of the business that cannot boost revenue. “Investing” in them doesn’t really make sense beyond nominal amounts because the max return they can provide is eliminating themselves.

Unless you’re into fraud, “accounting” and “accounts payable” are examples of cost centers. You don’t hire a bunch of innovative people to boost it because it’s not going to ever increase your revenue.

The distinction is made from a strategic perspective because scaling up “cost centers” should be avoided at all costs and scaling up “profit centers” is something you want to do as much as you can.

It has no overlap with “interesting work”. Very often the boring parts of an industry are the profit centers (e.g. in academia the profit comes from packing students into classrooms, not research).


I also disagree with the “cost centre” view, I think it’s often used too simplistically and doesn’t account for the fact that all areas should add value (otherwise you wouldn’t have them by design).

Some examples (that I have seen in reality):

Finance departments are cost centres, until you give them enough resource and they find you a more efficient tax structure. Cut finance departments start to struggle with things like credit control which affects your revenue.

Distribution Centres are usually seen as a cost centre, until you drop spend and it impacts COGS or customer lead times, or inventory in shops raises because of less frequent deliveries and you get out of stocks.

IT is a cost centre, but when funding is reduced change across the whole business slows and other areas are impacted (eg the customer web experience).

In reality the distinction of “some areas generate profit” and “some areas just cost” isn’t true in the end. All areas contribute to profit - some just do so indirectly.

I think the idea of Michael Porters “value chain” is better, where everything contributes to customer value (including indirect functions). The argument this makes is if you see some areas as just cost centres (e.g. fulfilment centres) then you can miss your ability to maximise customer value (e.g. offering faster delivery options).

Even sales people don’t usually generate profit on their own because without the other business areas they would be selling hot air.


I think this is exactly right. However, the question still stands: how does a large tech-focused corporation encourage engineers to pay attention to such requests?

Expecting enough of them to just volunteer their time doesn't appear to be a sustainable answer.


Oh, I agree with that - I just disagree with the cost centre view (most of my career has been in logistics which is traditionally a 'cost centre' while at the same time people complain about the service they get! In logistics there is a relationship between service and cost).

I spent a few years in IT as a Product Manager (or a similar role), and I viewed my primary role as protecting my team from the barrage of shit that I got, so that they could focus. This involved making sure I was politically the first point of contact and reducing back-channels (some are fine, but not ones that change functionality, involve significant work or are too distracting), placating the people requesting functionality or fixes by understanding how serious the dependency/issue was, triaging it and either placing it on the roadmap or saying no. We also had an engineering manager that could be the contact for specific bugs who could then triage and pass it on.


They are still cost centers. Being a “cost center” does not mean money can be cut from the department and the business won’t suffer. It means that pouring extra money and scaling up the department does not generate more revenue.


> Unless you’re into fraud, “accounting” and “accounts payable” are examples of cost centers. You don’t hire a bunch of innovative people to boost it because it’s not going to ever increase your revenue.

You're so, so spectacularly wrong on this, I am honestly gasping for air.

Accountants are the only people who know if your company is alive or a walking dead. How do you expect to run a company if you don't know reliably and with precision how much money it actually has/makes/spends? Money is the lifeblood of a company! Don't you want to be constantly improving the way you make, spend, and report it to investors and the public?

The biggest companies in the world typically end up with CEOs that come either from sales or from accounting. That is not an accident. Business is about money, and you want smart and innovative people to look after it. Conservative CFOs can be the death knell of a company, among other things.


> You're so, so spectacularly wrong on this, I am honestly gasping for air.

Calm the fuck down. It’s a conversation.

> Accountants are the only people who know if your company is alive or a walking dead. How do you expect to run a company if you don't know reliably and with precision how much money it actually has/makes/spends? Money is the lifeblood of a company! Don't you want to be constantly improving the way you make, spend, and report it to investors and the public?

You entirely missed the point. At no point did I say accounting was not important. I pointed out though that investing more and more into accounting does not boost returns. If that were true, every company could just hire thousands of accountants to boost their profits. This is what separates a cost center from a profit center. Your department provides value in the same way that running water does. It’s critical and you don’t want to skimp on it, but it’s just a part of the business that isn’t helping grow the total market capture.

> The biggest companies in the world typically end up with CEOs that come either from sales or from accounting.

Why would you include sales together with accounting? Sales is precisely the opposite of accounting in this regard because it’s very easy to tie sales directly to revenue. So easy their compensation is literally based on it.

Not so hot take: CEOs that come from accounting and not a customer-oriented profit center are the worst. They know what the numbers look like but are fundamentally disconnected from why customers give money to the business. Seeing the minutiae of the ins and outs of money gives a super false sense of understanding the business. Accounting CEOs are terrible in any industry that requires innovation or getting ahead of trends.


I generally agree with you about not dismissing the value of accounting.

However this:

“Accountants are the only people who know if your company is alive or a walking dead.“

I disagree with.

A walking dead company is only walking dead until one of its initiatives pays off.

The accountants will only know this after the fact, whereas numerous other functions may know it to varying degrees of confidence before the fact.


> The accountants will only know this after the fact

The accountants know when your debits have to be repaid, how likely they are to be repaid or refinanced by then, and what the penalty for not doing so will be. I'd argue that, in most cases, nobody employed in the development/production chain will have that information, possibly not even the CEO.


Sure, but accountants will not know the likelyhood of success of a new product or service, how the features will affect sales, the likelyhood of making large sales, the state of strategic relationships, etc. etc.

Yes, they may have models and estimates, but the real information will be in the hands of those involved directly.

Even things like refinancing and the options for doing so can be affected by things like letters of intent from potential large clients, industry validation, etc.

Just knowing numbers and dates isn’t enough.

I’m not saying accounting isn’t important, but it just isn’t the only source of truth.


You're missing the lack of creativity and courage in the managerial class.

Support can very much be a profit center. Support personnel is relatively cheap; if their services are priced correctly, they can easily become a stream of recurring income - and everybody knows that "recurring income is best income".

However, this requires efficiency and creativity at the managerial level. It's easier to see support as a burden and just work on shrinking its costs, instead of maximizing its revenues by formulating good price plans. The former is an internal effort that is fairly easy to implement in short timeframes and will easily win brownie points with direct superiors (who doesn't like to cut costs?); the latter requires actual pricing skills and market knowledge, and might take a while to get results. The mediocre manager will always prefer the former.


I feel like this is a double edged sword. Corporations have already embraced this idea of converting cost centers into profit centers and it makes life more difficult for consumers. Every time I call support at my ISP, because my internet is down, they work on my problem and tell me that my plan is slow and that I can upgrade my package for an increase in my bill.

This sets up perverse incentives, that as far as I can tell, are theoretical, but have potential to become more prevalent. Because of the cost center as a profit center idea, my ISP can generate more revenue by providing less value to me. If failing infrastructure causes me to call support more often, and more support calls increase the likelihood of more revenue, why should the ISP invest in better infrastructure?

The key to having a successful business is to carefully align the incentives of specialities in an organization to make the most competitive offerings to the market. If there are competitors, and customers can switch to them, and the competition is more compelling, then I would go to other ISPs.


I agree that what is good for an individual company is not necessarily good for consumers or the market as a whole, and that there is always a balance to find, but that's another issue. After all, the ideal scenario for a company is to have customers pay for support without actually using it most of the time.


Not much.

"Cost center" can be transformed into something else given both an understanding that support can and should contribute to future sales, and an organization capable of putting that understanding to work.

I have seen a similar scenario in manufacturing where various setup, prep, quality tasks are seen as cost centers and minimized.

Doing this kind of thing has ripple costs. Always.

In a perfect world, we make software, or hardware, and it just works and people grok it.

In the one we live in, these are fantasies and we can choose to understand, recognize the value, or not and get the benefits or not.

The users, customers, move from role to role, and support often determines their willingness to use the product again. That is straight up powerful marketing by referral.

Support often is the first to understand a user, customer needs an option too, or add on, replacement, preventative maintenance. Done right, these leads into lean, consistent sales.

"Cost center" to me has always been a bit silly in this way. There is opportunity to add value throughout the chain of people, process, machines, systems that are all necessary to properly conceive, realize and deliver something to others.

One thing often missed along with failing to understand value is failing to ask to be compensated for it.

Doing things in a robust, high value for the dollar way is not the cheapest way, in terms of raw product price, and depending, size of margin.

But, we do get what we pay for too, and the lowest price often comes with externalities paid by both the enterprise and its customers too.

Sometimes I see this all framed as a luxury. That is just as much of an error, and does come with unnecessary costs and or poor alignment with actual value.


Our support team is not technical in any way (they are support for our entire moderately sized membership-based nonprofit), but they are consistently a source of extremely high quality feedback, for the reasons you mentioned.

If there are serious UX issues, your designer might not uncover them, but support will hear about it. If there are edge case performance issues, your dev team might not uncover them but support will hear about it. Very few people know more about how real users interact with your products than support.


Word

I should have included that. Glad you did.


> What am I missing?

not much, or everything -

it's basically an accounting term on how you are tracking an expense and so it is very insightful as to how the effort of your project,group,department etc. is perceived by upper mgmt

so "we don't find this work to be valuable or interesting, and we'd like to do the bare minimum of it - in fact, we'd like to unleash smart people to explore new frontiers of just how minimal the bare minimum could possibly be."

is pretty spot on, if the effort has been (mostly arbitrarily) categorized as such..

when i learned the accounting theory behind it, it suddenly illuminated managment attitudes in current/previous jobs - literally in some orgs overly reliant on this perspective there is literally nothing certain efforts can do through official channels to be viewed as 'valuable' ..


Originally everything was a cost centre, but some rebranded as profit centres, and the PHBs swallowed it.


You should have shared you wisdom with Boeing in 2010 ...


x% of support requests are of questionable nature - to mention just a few categories:

* people expecting to use a sophisticated tool (for doing complex business processes requiring special know-how) without paying for and spending time on adequate training)

* people unwilling to RTFM, google, youtube, etc.

* people whining when a general purpose tool doesn’t fit their exact workflow to a tee


Those are all sales and service opportunities, BTW.

Back in my support role for higher end software, I flat out hit numbers comparable to sales and generated a ton of great leads.

Fact is, people do what they do and they have their reasons.

Judging them and acting on that judgement by marginalizing an important and necessary part of the process has a higher net cost to the world, and often the enterprise, than just doing those things reasonably does.

Net happiness goes up too. True for the enterprise and users, people at large.


Not all sales and service opportunities have positive ROI


There are no free lunches. Expecting otherwise is a very good sign the enterprise is penny wise, pound foolish.


Not every business environment is captured by grand sweeping general statements. Reality is a lot more nuanced than that.


Precisely.

And the fact is, enterprises seeing to make every support transaction a positive ROI are, in fact and in deed, penny wise and pound foolish.

They will see an opportunity cost due to missed sales opportunity.

They will see greater load due to people using an inferior process and poorly empowered people, repeatedly.

They will see a diminished overall market perception.

Their products will provide less value due to a greater misalignment with both exiating and potential users needs, which drive perception of value, which drives more dollars.

Personally, having been on all sides of this matter, I rank what we are discussing at the very top when considering who I will buy from and or work with.

Flat out, when I see enterprises putting seriously crazy amounts of money in the bank, I accept zero excuses in this regard.

It is not necessary. Lives are short, money hard to come by. Best get solid value for the dollar.


I generally agree with your arguments when the customers are medium to large businesses - and I assume that’s where your experience is. In the consumer and small business space the dynamics are very different.


Been there. They aren't. Some of the mechanics vary, but good service does not.

Right now, I am in the small business space and rock solid support is how we are killing it.

Been there, very large, small, medium, consumer, b2b...

Don't tell me it can't or should not be done when billions land in accounts free and clear.

It can. Should.

I spend with those who get that first and foremost.


Maybe you should quit your current career arc and help companies change their attitude and thus unearth extra billions in profits?

And I don’t mean that cynically - since if it’s as easy and guaranteed profitable as you say, why wouldn’t you be able to convince numerous CEOs to unearth all of those extra billions?


It is all value judgements.

Again, if the priority is to always have a positive ROI, and that metric is computed every quarter, without due and inclusive consideration for externalities?

All the things I discussed here are going to get watered down. And it is always the same priority on max dollars now, max recurring dollars now, and WGIF about the future, others.

Where that happens, so do the things I just said. Not my mess to clean up.

Some enterprises get it. They get my time, attention, dollars and referrals first.

Beyond that? Got better things to do.

Clearly you value things differently. That does not make anything I said wrong.

Take care. You get last word on this.


> Customer support is a cost center

For us, great customer support is one of our stronger sales arguments. In fact we've not had to push hard on sales due to our customers calling former colleagues who moved to a competitor to tell them "you have got to get this software". Having great support has been key to this experience.

Most of our support people have been recruited from our customers, so they know not just our software well but the processes and regulations around it, allowing them to quickly understand the issue at hand and offer relevant help.

So while it might look like a cost center on paper, I'm quite certain it's a massive net gain overall.

Of course as you say, we work hard to mitigate the cost of providing that support, like routinely looking at implementing changes that'll reduce repeat support issues. Maybe as simple as reworking a dialog text, to adding more automation.


Yup that's accurate. I was a regular old support drone who had some connections that allowed for some special paths to engineering.

We had 'official' faster escalation paths but those inevitably are determined by $$$ and there's always more ways to measure 'important customer' than can be defined / shown in $$$.

Management was totally aware of it all and supportive.

But eventually I got tired of the land of 'support' and moved on for a variety of reasons, mostly because time and again I saw support treated like the usual 'cost center' and I didn't want to be a part of that.


> What management needs to realize is that this is also an important interface point which requires attention. This doesn't happen at all, or is inconsistent.

> What I've always found interesting, is that all of these are often failing in some way at the same time in an organization of any size.

The formalization of it is frequently the cause of it failing or being inconsistent. Once it's a workflow that's explicitly acknowledged and condoned by management, it will start to lose its effectiveness. As an official express lane between customers and engineering, every account/sales person will become aware of it and overload it, either in the general course of supporting their client portfolio as much as possible, or even worse, by making this internal express route known to clients, as they can get incremental revenue by branding it as a "VIP Support" service or to make at-risk clients feel special. Which will eventually end up in actual client contracts in some form or another, opening the door to client abuse (or misuse) as well as causing legit cases that would have gone through this implicit channel to get routed to and trapped in normal support because the client at hand didn't pay up for the express lane.

You've also replaced a channel built off of relationships and mutual trust/respect into one based on official responsibilities and inertia, and all the hazards that entails. Such as political/managerial turf wars that add friction to the process, as well as cost minimization efforts that deskill the role over time and profit maximization efforts that overwhelm the capacity of the role, alienating the engineering team and undermining the entire intent.

... not to say it's impossible. But that's generally why you'll see it failing in some capacity any time you witness it, because it's almost impossible to maintain equilibrium the moment you officiate it.

An alternative that tends to be more lasting is for management to _actively facilitate organic growth_ of these sorts of things. Enable and encourage and provide opportunities for inter-departmental relationships and lines of communications to form. That way there is no single "back channel", and organic lines of communication between different parts of the org are robust against the loss of a single node.


The biggest problem we have in software engineering is the lack of support staff. You don't think a civil engineer has to deal with minutiae of paperwork, but software engineers for some strange reason think it is ok to be inundated by clerical work all the time. The industry eventually must evolve to create software assistants capable of running code, triaging bugs, etc.


> The industry eventually must evolve to create software assistants capable of running code, triaging bugs, etc.

In my opinion, we had this. They were your senior support staff or were operations; some companies combined this into a formal role called "Support" or "Service" "Operations."

But then we as an industry decided that operations is bad[0] and if you write the code then you can obviously test the code, deploy the code, maintain the code, and support the code. Then every Hip And Cool Start-Up adopted the model of "sysadmins and support staff are bad because we've had bad experiences in the past so we will also have our devs talk directly to customers until they get tired of doing that and we just replace it with a contact form encumbered by CAPTCHA and a no-reply e-mail address."

As someone who has greatly enjoyed, been very good, and very well paid (so my employers agreed that I was good at it), at support and operations roles only to see them disappear into the inky void of Everyone Codes All Of The Time, I am both biased and frustrated.

0 - Because money, I suspect.


There are still lots of good support organizations out there, and not every place looks at support as a burden. It's a pretty critical piece in the "new" 'as a service' world, helping folks use complex systems that they don't control, etc.

I've been heavy in the data space, and get to do some fascinating work with folks, helping design data models, implement analysis, and other things in a wide variety of verticals. It's support, so sometimes there's some more tedious things too - there's no avoiding that. :)

But, and perhaps I'm biased, it's still a great career path, even if it's not as flash as "code all the time" work.


I think this is an indictment of the lack of organizational skills in the area of software engineering. It is still an industry run by the sit of their pants. There is no clear separation of responsibilities and everyone wants to do everything (and usually badly).


It's funny you mention that. I was a support drone when I was in the situation I described above.

But support being support ... it is eventually devalued and I chose to learn to code to move out of those types of roles.

When I moved on (through a somewhat handy acquisition and layoff and etc) some engineers reached out to me to join the support team there.... but I was done with support (and other factors).


In my company, there is a blurriness between support and technical sales, and while that can be a little chaotic, one benefit of that approach is support is looked at as a profit center to a degree. This is because the support people keep an eye out on upselling, maintaining subscriptions, and promoting consulting work. We're not obnoxious about it, but there's some awareness that part of the role of support is to promote the long-term growth of the customer relationship and sales.

I think if there was a stricter division between support and technical sales, there would be more of a temptation to focus on burning through support requests as quickly as possible. The flip side of this is that it is easy for us to get bogged down in a complex half-support half-sales opportunity situation and that can sometimes cause other support requests to fall through the cracks.


There is a fine line between running interference and sales prevention.


Just for reference, the pair is spelled "yea or nay" rather than "ya or nay".


That sounds like a dream career -- any advice getting there when you've hacked on graveyard startups most your life?


Stuff like what the parent described tend to be "on top" of your day job, rather than your actual day job.

Parent likely established a working relationship with individual(s) in engineering organically over time, and at some point leveraged that relationship to ping them about a customer issue that crossed their path and seemed to be an engineering concern vs user-error. That didn't cause waves and went well, and got repeated enough to become an established but unofficial "thing" parent was capable of, and they became known by a few sales/account folks as the go-to person when they felt a situation may warrant that unofficial route.

You can make a career off of doing this sort of thing, but I'd caution against it. If a company is hiring for specific scenario of "fast lane between client and engineering", the actual job is "support with special escalation privileges, servicing clients splurged for the premium package". You get all the soul-crushing hell of working a normal support role, but with the added benefit of solely servicing clients that expect you to hand them the world because they paid extra for it. Which is far closer to a nightmare than a dream; particularly considering someone working one of these official roles likely has the skills to pivot out of the support org and into the engineering org in some capacity, and drastically increase their salary potential while simultaneously improving their quality of (work) life.

In a more general sense though, pretty much any career benefits from doing what the parent described. It's effectively just flexing your soft skills and establishing relationships with people outside of your immediate sphere/department. Which has a tendency to make it easier for you to get things done, and garnering a reputation to that effect.


It wasn't an official job.

I was a regular support drone as far as anyone knew.

I just had some connections that came about because I could be discrete and the engineers understood that I didn't bring them garbage too early (without enough information) or without good reason.


And this is why it's important to recognize and retain people who get the right things done. One does not simply backfill a support position and replace someone who has built up the internal AND external reputation and relationships required for issues like this to get fast-tracked and fixed in a way that makes everyone happy.


Soft skills are key; getting to know key people, and their responsibilities and capabilities and personalities.

But above all: be a good listener. Listen to what they say, think about it and build it on next time you talk with them. If they see you showing interest and learning about their domain, you'll get a direct line to them. And don't always bring them problems, be sure to stroke their ego too by asking what they're working on.

It doesn't happen overnight, it requires perserverence and a dollop of luck. You won't walk into a job like that, it takes years of building a reputation for yourself.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: