Hacker News new | past | comments | ask | show | jobs | submit login

> Engineers are encouraged to interact with the rest of the business and build relationships with non-engineers. In contrast, traditional companies often make it impossible for developers to interact with the rest of the business.

In my experience “traditional companies” will often have a bunch of people in cushy “gatekeeping“ jobs whose main function is basically forwarding emails back and forth between devs and the business. If you try to get direct access to the business usually the business is quite happy but the gatekeepers get very upset.

I work in a "traditional company" and the gatekeepers were installed to keep developers from going insane. When we have too much information back and forth between business and engineering, the loudest complaints from the business side (where the $$$ comes from today and tomorrow) drowns out the team's and department's internal goals, which are usually much longer term (meaning the $$$ is in months or years, not next week).

I believe this is why the author noticed that certain types of companies had engineers say the product owner was one of the reasons they're more satisfied. From when I started at my role, my team went about 2 years without one, and then within months of having one, we have been much more productive and have managed to create much more immediate and future value for the company.

The trick big tech uses to solve this is to not just pay extra for above average engineering talent, they pay extra for above average talent in all areas. So the people you talk to are almost always pretty reasonable and understanding, they want things done and complains but they don't ask for the impossible or unreasonable.

I think it’s deeper than that - these companies place product/engineering at the centre of the business, rather than at traditional companies that still see it as a cost centre.

There are also product managers and UX engineers. It's not like every random coder is interacting with sales on the go to market strategy.

Product managers and UX engineers are there to do product management or UX design, not to filter information from the rest of the company to programmers. That means that most of sales requests are better forwarded to a product manager or UX designer, but there is nothing stopping them from directly filing a bug report to a developer and chatting about potential fixes/timelines etc. Also if some feature is important the product manager can just tell them to talk directly with the relevant engineer to get the feature done.

This is because businesses chronically underinvest in developer/engineering resources.

Developers tend to be viewed as something that is not "core" to the business, and generally only necessary on a project-by-project basis. So, projects are initiated, resource needs identified, and, since nobody wants to hire a bunch of full-time staff, most likely a consulting firm or off-the-shelf product is selected and configured.

The downside is now you have a thing that needs to be maintained, and probably it will be maintained by a limited pool of "in house experts", who are also responsible for just about everything else.

The net result is that you've got this centralized resource that is under provisioned and, well dear reader, what does your training as a systems engineer tells you will happen with a centralized resource that is under provisioned? Contention? Rising latencies and queue lengths? Disastrous to recover from failures?

You betcha.

You think they would be taken aback by the cost of a temp developer. In my case we easily charge the salary of two or three junior devs for one person and we are very sticky...not one contractor was out of work during the pandemic while those companies laid off FTE in significant numbers.

The problem arises when the gatekeeper either no longer understands or no longer cares why their position exists. Then they just become an obstacle to the very communication they are supposed to be there to facilitate.

I've also seen some instance where gatekeeper were pretty effective at filtering users demands because some of those requests were too dumb and the "paying" users were used to have everything they wanted, and because they "paid" the dev department, "they had to do everything they wanted".

Like asking for a 6months dev work to help them save 1 hour annually on an annoying task they had to do.

My experience has been the exact opposite, if the developers understand what the business is trying to accomplish and what the incentives are then they are in a much better position to prioritize and build the right thing. Every single time I’ve seen 6 months of work on a useless or low value feature it has been the result of the dev team getting requests via some PM telephone game.

This is a tricky balance. Developers can also get overwhelmed with requests for estimates, automation tasks, etc etc, and get annoyed that people have so much contact with them. But it is a tricky balance; there's no obvious solution.

Sometimes it's helpful to have some division of labor between field/sales/support engineers who go to handhold customers, understand their particular problems, and prototype fixes, and "product engineers" who have less customer interaction. This is somewhat similar to the SRE/SWE split at places like Google.

If I were designing an organization with such a division of labor, those wouldn't be different job descriptions but different activities within a single job description; maybe I'd spend 22 days a month doing product-engineer stuff like adding features, and 3 days a month doing support-engineer stuff like visiting customer sites, diagnosing customer problems, and answering calls, while maybe hatchnyc would prefer to spend 22 days a month doing support-engineer stuff and 3 days a month doing product-engineer stuff. The reason is that, doing either activity, you gain an enormous amount of knowledge that's crucial to the other activity, but very difficult to even put into words, much less into a knowledge base.

Bill Gates found it useful to answer tech support calls as late as 01989: https://www.entrepreneur.com/article/289857

> Bill Gates found it useful to answer tech support calls as late as 01989

This is good, but it's easier when you're a very extraordinary human, and your own boss!

Yeah, but Bill Gates managed to do it too.

> Like asking for a 6months dev work to help them save 1 hour annually on an annoying task they had to do.

I see this as a complaint a lot, but... in a private company, they're the ones writing the checks. So if they want to spend hundreds of thousands of dollars to save an hour, that's their prerogative. It's certainly our obligation to point out the cost (including ongoing maintenance) but again in a private company you don't really have the option of saying "no" except with your feet.

Yea, I don't see the complaint here. It's part of my job to let whomever the client may be that what they're doing may be a bad use of resources (typically in a documented email in a very positive tone with lots of "decision makers" on the email, also with a nice lead in explanation as to a way it could be efficient under some set of circumstances so they can copy paste that as their "well we weren't sure" pathway forward).

After that, I really really don't care anymore, that's someone else's problem. I've played that soapbox and it's a waste of my time and energy. I make sure responsibility is passed back, documented and proceed. If you want to throw hundreds of thousands or millions at me and whomever to some wasteful request, go for it. You have the option, you've been warned, and I've given you a valid excuse to proceed with high risk, high uncertainty of ROI option with everyone important involved.

I do a lot of contractual/consulting work so even warning can mean early termination of work forward, so I'm taking a risk even informing you (some people actually listen and work stops early during consulting time and development follow up never occurs, these are the smart people and they're bad for my livelihood)--I could just do whatever you ask and get paid. If I were salaried, there's even less risk of me losing income forward by informing so I say in those cases just do your professional due diligence go let people know it's a bad idea without creating political land mines for anyone, then allow them to step on land mines at their own discretion.

There are other factors at work that may exist outside of the "1h of labor saved" too.

It could be something that's tricky. While the optimal case is 1h of work, if something goes wrong then its doing forensic auditing on the books in 3 months and spending lots of time there.

It could be something that needs to be repeatable. Yes, it's 1h, but before this was done Alice did it and before that Bob did it. They did it slightly differently and that cause problems. Having a computer program do it provides change management to the process of doing that task.

It could be something that needs auditing. Tying into the previous two, having a "this is how it's done and all the calculations that go into it along with a test suite" makes it easier to be assured that it is working correctly.

There are lots of things outside of the purview of a developer working on doing whatever task needs to be done to solve a problem. The value of the problem being solved is the issue of the manager or the customer.

> in a private company, they're the ones writing the checks

As long as they're being otherwise reasonable, I don't have a problem doing something that doesn't seem terribly "important" to me either. However, in my career I've had many frustrating instances where they were demanding something in a timeframe that I couldn't deliver it without ensuring that there wouldn't be any unintended side effects - and then blaming me for the side effects when they came up. I only push back when they don't realize how complex what they're asking for is. Of course, then they play the "tell me how long it's going to take so I can argue with you until you agree that it will take as long as I originally asked for" game.

> they were demanding something in a timeframe that I couldn't deliver it without ensuring that there wouldn't be any unintended side effects - and then blaming me for the side effects when they came up.

Far too few developers understand: just because the people writing the checks ask you to do it and you implemented it exact as they ordered you to doesn't mean the people writing the checks will take responsibility for the resulting bad situations that can lead to them not writing you checks anymore. If anything, you'll be used as a scapegoat to prevent them from not getting any more checks written.

Of course you have the option of saying "no" unless the company culture / leadership climate does not allow it. That's far from the inherent obligation you're describing.

I do however agree with leaving any organization that does not allow you to express disagreement.

I think that depends on whether "no" means a nice way of saying "this is stupid" - which I agree with, and have done before, to mixed results - vs. outright refusing to do work that's been requested. I don't think an employee who is being paid a wage by an employer has the right to refuse to do something just because it's a stupid idea.

I'd much rather have an employee who will refuse to do work that is stupid than one who will do whatever is asked of them. Especially if it's something as bad as the GP example of six months of dev work to save one person-hour per year.

This is really only true of it's coming from the very top of the food chain. Sales is obviously an important part of the revenue stream, but it's not the only part and it doesn't automatically trump all other concerns. For example, it's not useful to sell a product that doesn't work, will cause huge customer churn and will destroy the company's reputation. If you're a shareholder or care about the longevity of your job, it's important to push back on wasteful behavior.

Absolutely agreed, I implied with "writing the checks" it was the actual owner(s) of the business making the decision but could have been more explicit about it.

Completely agree on that.

Now imagine a government entity where the users and the dev are both paid by the gov.

I have seen it more often that gatekeepers filtered user demands based on their own knowledge and not on technical feasibility or effort. So you are told that a user needs a certain thing in a certain way but when you talk directly to the user you learn that the user actually had a different need which you can fulfill in an easier way than the gatekeeper thought possible.

In general I think there is a huge advantage if developers know first hand how their product is being used and not through gatekeepers.

The whole point is that this doesn't scale. What do you do when there are too many users to interview them all over coffee?

Honestly that's the whole problem with Democracies. And we solve it with sampling and surveys. Probably if we can come up with a better answer, we will improve Scrum, and Democracies :-)

You have key business ops people AND their key users (direct reports) involved. It scales.

Unless you work on an internal tool "business ops" are not your users. I'm talking about real products with external users that are only really identifiable as an "account" unless it's a massive contract with dedicated sales team.

Even when the possible goals are identified, someone has to prioritize them at some point, since there are always more goals you could achieve than goals you will achieve. To prioritize, you need to know both the benefit of a goal (which is really a probability distribution, not a number) and its cost (which is notoriously a wide probability distribution before you have done it). Sometimes this involves trading off the needs of different "goal donors"; in XP these all filter through a single "goal donor", confusingly called the "customer", who decides how to order the cards in the box once they're estimated. The goal donor (who may or may not be the gold owner, another confusing name) can reorder the cards at the beginning of each iteration, either because new information has appeared about the benefits, about the costs, or about the possible goals.

It sounds like what you're describing is the lack of such prioritization. It isn't necessary to keep the developers ignorant of new user "demands" in order to prioritize them; they just need to be empowered to follow the priorities the team has chosen instead of accommodating every demand.

Sometimes it's easier to accommodate a demand than to write up a card and estimate it, though. Sometimes a bug fix or layout tweak is obvious enough that doing it takes only a minute or two; then, it's just a question of process overhead whether the actual cost of doing it is five minutes or five hours: potentially multiple forwarded email round trips, a fresh checkout, pair programming or other code review, compilation time, test suites, commit comments, merge requests.

Usually, in my experience, if you have extreme overhead, most of those changes never get requested, because they don't get prioritized the way they would with the order-of-magnitude lower cost a lightweight process can provide. The result is that they never get done, so the product is full of easily observable minor problems, which is experienced as shoddiness.

The gatekeepers are the ones with the people skills:


What a utopia this movie portrays! Individual cubicles, administrative assistants for senior staff, and the protagonist has only been asked to work over a single weekend.

Funny to look back. Here's Intel's HQ: https://www.youtube.com/watch?v=XrZrTJqK7ys

All I can think is "Wow, I bet I could really focus on something difficult in that cubicle!"

... and, unpopular opinion, business attire!

Yeah, I learned the hard way that one of the worst things you can say at a megacorporation is "this manager is just creating work to justify their existence in the company". In my case, it was directly applied to a specific manager (who heard me say it), and it led to me being lectured and yelled at and told that it was "unprofessional" talk (which to be fair it kind of was).

Yelling at people at work is unprofessional. Sometimes it's illegal if you are a federally protected class.

I'm definitely not a protected class (I'm a tall white dude), and I am not being 100% fair; they weren't screaming at me or anything, just an elevated voice and very angry words. I don't believe they said any curse words, and even if they did I was somewhat sympathetic to why they would be upset with me (even though I do stand by the content of what I said).

It was probably still unprofessional, but probably not as bad as I made it sound...my bad!

At the last large traditional place I was at it seemed a lot like the upper management types had put these gatekeepers in place so they had people that would pander to them. The amount of times one of them told me they couldn't tell their boss some bad news for risk of getting fired or chewed out, but wouldn't let me go and tell them the truth was mad.

From what I could tell no-one was firing engineers because it was too expensive and we didn't really care since we could get more work within a few hours, and the "bosses" didn't like the lack of power they had in that dynamic.

A clear implementation of the Thermocline of Truth - https://brucefwebster.com/2008/04/15/the-wetware-crisis-the-...

Yeah that all sounds very familiar.

As an aside, his other posts of the Dead Sea effect - http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-d...

And Anatomy of a runaway IT project https://brucefwebster.com/2008/06/16/anatomy-of-a-runaway-it...

Those are fun reads too.

The best arrangement is to have business report to business and engineers report to IT, but have them communicate directly. This was they can't be pressured by business into short term tasks, because they are on the same level and not just mere subordinates of business folks.

In traditional (not engineer-first) companies, engineers are subordinates of PMs or business directly without their own agenda, so they just accept the fate and become a feature factory for the company.

Constructive / progressive organizations can be built or transformed into, where collaborative knowledge-work happens at all levels.

Scrum is a parody and pretty much anti-agile.

Traditional organizations are driven by the cost-accounting mindset that creates gate-keepers and makes it impossible to share a common purpose, let alone collaborate across teams, units or vertically.

> In my experience “traditional companies” will often have a bunch of people in cushy “gatekeeping“ jobs whose main function is basically forwarding emails back and forth between devs and the business. If you try to get direct access to the business usually the business is quite happy but the gatekeepers get very upset.

“But I’ve got people skills, dammit!”—Tom Smykowski

My current company is like this. I work directly with the business people anyway. When anyone says anything I just point them to my output, quality, and the feedback from the business people - shuts them up every time.

I’m one of these hypothetical gatekeepers and would be thrilled if a dev could successfully take this off my plate. Just prioritizing the incoming requests from stakeholders is a full-time job.

I wish I could upvote this twice. So true, it's very frustrating.

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