

Speeding Up Your Engineering Org, Part I: Beyond the Cost Center Mentality - ojrac
http://blog.hut8labs.com/speeding-up-your-eng-org-part-i.html

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

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

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

------
melindajb
I loved this and would go so far as to say that anyone working a tech company
who isn't an engineer needs to read this post and pretty much all the posts on
that blog. They do an excellent job of breaking this stuff down and helping
you understand why engineering is not the same as manufacturing teh widgets.
The latter is all about creating and replicating efficient processes; the
former is about sui generis creation, like sculpture.

FWIW in my mind after all these years, I've come to some of the very same
conclusions but these do a great job of articulating WHY. Sort of like
learning to play music by rote vs learning to read music.

So in my "not a developer" mind I've chalked it up to the fact that every
website is a cathedral. Each one is different. Each one is built by artisans
from scratch.

But this post and other posts on the blog really explain exactly why each site
is unique and the issues around research in a way no other engineer has ever
explained to me before. Now I fully understand what to look for and how to ask
for it. I'd had product owner/scrum training so I thoroughly understood story
points, break stuff down, but the clincher for me here was the idea of
prioritizing the smaller stories that help us learn quickly, almost MVPing the
MVP.

Again, this is stuff I've sort of picked up over the years, but what a gift to
help others skip that way of learning. These need to be in a book and they
need to be taught to anyone working in technology.

------
polskibus
The article reinvents Lean values, principles and actions, wrongly attacking
"cost center" attitude as the source of the quality problem.

Lean paradigm values flow efficiency and quality at the cost of resource
efficiency (think mass production). You can balance somewhere between
depending where what your business strategy is, but it is important to
understand that maxing out flow efficiency and resource efficiency is
impossible.

Saying that cost center approach is wrong, is misleading and targetting the
wrong problem. There's a tradeoff there, it's not good vs bad.

There's a good book I can recommend for people interested in Lean and its
position vs mass paradigm: "This is Lean: Resolving the Efficiency Paradox".

------
ojrac
Interesting idea - people don't think about the real value of quick turnaround
times in the same way they think of spending the developer hours to move
faster.

