Skip to main content

Engineering-drive organisations

Last post 06:30 pm March 15, 2018 by Jeffrey Verona
2 replies
09:06 pm March 11, 2018

Hi

I am on the infrastructure side of the house but am interested in learning about Agile to make our organisation more effective. I came across this article here;

https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especiall…

In particular, 

"Silicon Valley has gotten a lot wrong, especially in the past five years, but one of the things that it got right is the concept of the engineer-driven company. It’s not always the best for engineers to drive the entire company, but when engineers run engineering and set priorities, everyone wins: engineers are happier with the work they’re assigned (or, better yet, self-assigning) and the business is getting a much higher quality of engineering.

If your firm is destined to be business-driven, that’s fine. Don’t hire full-time engineers, though, if you want talent. You can get the best people as consultants (starting in the $200-per-hour range, and going up steeply from there) but not as full-timers, in an business-driven company. Good engineers want to work in engineer-driven firms where they will be calling shots regarding what gets worked on, without having to justify themselves to “scrum masters” and “product owners” and layers of non-technical management.

Ultimately, Agile (as practiced) and Waterfall both are forms of business-driven engineering, and that’s why neither is any good at producing quality software or happy employees."

Would this forum agree that Agile (and Waterfall) for that matter are business drive engineering as opposed to engineering driven? If so, what is an example of a methodology that is engineering driven? Are Google, Amazon, Microsoft etc engineering driven?


10:59 pm March 11, 2018

I’d say that waterfall processes are push-driven by stage-gates and schedule, while agile ones are pull-driven by evidence and flow.

Referring to companies as being “business driven” or “engineering driven” seems more like an assessment of certain organizational schisms or cultural imbalances which have been allowed to arise.


04:30 pm March 15, 2018

I too read his article but most businesses have a profit motive or are trying to deliver a service/product to a customer to address a customer problem.  Neither "engineering" teams nor "business" teams can fundamentally ignore this fact.  As Ian states, this seems to be an observation about organizational culture since many "engineers" go on to lead and run companies as "business" leaders.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.