Comment by michaelochurch | Hacker News Reader

Comment by michaelochurch | Hacker News Reader

OP is very long and makes a fundamental mistake. It tries to save business-driven (or product-driven) programming. You can't. Even if you could, it wouldn't be worth it. Technology can't be "driven" by people who aren't skilled enough to evaluate and prioritize the work.

Two years ago we agreed to hack it up quickly in PHP, but product promised us—PROMISED—that we would have time to go back and clean it up.

If "product" is deciding how much time engineers have, then the organization is fucked and deserves to fail. Running a technology company like that is like letting 5-year-olds fly a plane.

If you’re a mature, business-focused engineering leader, you might grab some coffee, sit Cindy and Scott down, and tell them something like this:

“Cindy, I’m sorry to hear that you’re getting bored doing so much production DB work, but realistically it would take you at least 40 hours of work to write, test, and deploy a migration utility, right? So if you’re spending a half hour a day on migrations, it would be 80 working days before we saw a return on our investment—that’s like 4 months, and that’s just too long for me to sanction—precisely because you’re such a valuable member of the team, and I can’t spare so much of your time right now away from our feature backlog. We can touch base if the migration workload increases too much, OK? Until then, I have to ask you to put your head down and be a team player.

I agree that that's a wrong approach. I go further. That hypothetical manager is being a condescending, passive-aggressive dickhead. "Too long for me to sanction?" What ever happened to supporting your people? I can't afford your time? Are engineers slaves now? If I got that ration of shit, I'd be changing jobs in a week.

I agree that the cost-center mentality is toxic, but the OP doesn't go far enough. OP seems to think that non-technologists can run technology companies. We have mountains of evidence that shows that it doesn't work. We need something like what the lawyers have (lawyers cannot, by law, report to non-lawyers) if we want to see actual technical progress in this country.

I.... I'm not sure you got his point.

Steve Jobs was not a technologist, but he seemed to do a fine job of running a technology company. Bezos is not a technologist, but he also seems to be doing ok.

The argument here is basically that the apparent opposition between what business wants and what engineering wants is mainly illusory. That if you think about business correctly, a lot of engineering desires are exactly what the CEO should want.

The "engineers must control all the things" urge is exactly the same one that managers have. It's really, "People like me must control all the things." The reality is more nuanced, and more mundane: giving a single viewpoint control rarely works; what we need are contexts where people respectfully collaborate.

I think the reason this attitude exists is because the barrier of entry for engineering is higher and more concrete than it is for marketing, or sales, or product. Most people can walk into an entry-level marketing job and get things done, at least poorly. The same isn't true for an entry-level engineering job-- it's literally a nonstarter if you've never written code.

The truth is, very high level marketers or sales people or product managers are every bit as rare as very high level engineers. And at some point in your career you realize there's a crapton of expertise in those areas you don't have, but others do. And working with them and even deferring to their judgement in those areas gets you a lot better results than getting to be king of the castle.

Bezos is definitely a technologist - he was a quant at D.E. Shaw, which is basically the Google of hedge funds. Possibly even more prestigious than Google; D.E. Shaw is known for being ridiculously difficult to get into.

Steve Jobs is clearly, to me at least, the exception that proves this rule.

> Technology can't be "driven" by people who aren't skilled enough to evaluate and prioritize the work.

And what makes engineers the ones who are skilled enough to evaluate and prioritize the work? They understand the technology side, but do they understand what customers want and need? What will sell and market well? How a product will fit into the company's product lineup? What the competitors are doing? The problems customers are calling support about? Etc.

There are many competing priorities, and I don't think any one person or role can know enough to be able to accurately prioritize what work is most important. You need a team that works well, and members of that team need to be able to clearly explain the benefits and costs of doing or deferring any important piece of work.

As an engineer, we need to know those costs/benefits and how they trade-off against other tasks to make the right decision of which one to do first. That doesn't change if you're the one with the final say, so why does it change when you have to communicate it to a PM so they can weigh it against the other work to be done?

In the OP, the manager is doing the cost/benefit analysis. If Cindy and Bob were great engineers, they would have done a similar analysis themselves.

There is an argument to be made that if your engineers don't know what makes a good product, then they cannot build a good product. It's like asking someone with only a theoretical knowledge of music to build you a violin. With experience and careful guidance by a team of violin spec writers they can probably approximate a violin, but it will not be enjoyable to play unless it was made by someone who understands the needs of a violinist.

So anyone running a company with lawyers is a lawyer?

Lawyers answer to other lawyers, up to the GC, who reports directly to the board.

Law firms can't be publicly-traded or owned by non-lawyers.

It makes it hard to liquidate, but it's generally good for them. It tends (at least in theory) to give them the autonomy and respect of a true profession. In truth, it's never that simple, but the idea is right.

Would the appropriate engineering analogy then be professionally recognized/credentialed technology teams rolling up into to a similarly credentialed General/Chief Technology Officer who also reports directly to the board?

If we believe wikipedia, GCs used to mainly report directly to the CEO, and still do for smaller firms. For larger firms, it's not unusual for GCs to report to the board in conjunction with CEOs[1].

Going back to the idea of technologists reporting up to technologists, this is probably the same end state where the Professional Engineer (PE) designation for "software engineers" in the US is ultimately trying to get to. I think it's the NCEES and IEEE that are driving this[2].

It doesn't seem to me that you'd endorse the NCEES-IEEE vision for other reasons articulately expounded on at length on your blog, but would like to get your thoughts on it nonetheless since I don't think it's been touched on much in this forum recently.

[1] https://en.wikipedia.org/wiki/General_counsel

[2] http://www.todaysengineer.org/2009/Sep/Software-PE.asp

Got it. So the equivalent would be for CTOs to report only to the board?

Reply on news.ycombinator.com