
Product Managers: How to get your engineers to love being lean - hanzq
http://blog.kera.io/post/37714288534/product-managers-how-to-get-your-engineers-to-love
======
ebiester
If you want this, then:

A. Let your engineers know they will never have to look or explain this code
to anyone, and

B. Their job isn't on the line if it doesn't work.

The reason your engineers want clean, testable, fast code is because they know
that the project manager won't be up until 3AM debugging the system because
it's down and there's a giant pile of hastily written code and technical debt.

(I agree with what someone else said that developing and selling your own
product really clarifies the importance of getting things out the door, but in
those circumstances the pain of no customers is more than the pain of the 3AM
debugging session.)

~~~
hanzq
That's very similar to a philosophy I have about feeling pain all the way up
to the decision maker.

If the decision maker (project manager in this case) doesn't feel any
consequences for their decisions, then they won't have any incentive to make
good ones.

------
MattRogish
“There are two types of startups... those that are successful on a code base
of which the engineers are moderately ashamed... and those that go out of
business.”

\-- Lean Startup 2012 Conference

Perfect is the enemy of good enough, and all that. Especially as a startup,
there's no guarantee you're going to be in business in a few months, and time
= money. I'm not saying you shouldn't have well-tested code, but you probably
shouldn't spend weeks perfecting something when a good enough solution can be
done in a day.

------
columbo
Good enough is a struggle... but the one thing that should never be pushed
down the pipe is ensuring the code is understandable.

Once you get beyond the basic crud-webapp-twitter-clone the ability for a new
person to simply pick up and start working becomes increasingly more
difficult. This is a cost that you _will pay_. You'll pay for it when one of
the three people that understand the system decide to quit or when you have to
put new hires through eight months of training before they can write a single
line of code.

I've worked with systems that were written by people that have decades of
industry knowledge. Every class, method and comment is using their lexicon and
entire chunks of the system rely on assumed knowledge. Suddenly
ranked_pct(std_dev_norm(userid,norm,v,arr,false,get_data(userid))) is
returning 0.24 when it used to return 0.51 and the BA/PM would like to know
what changed. That's when you'll realize that your growth has been severely
limited.

~~~
hanzq
That code blip sends a shiver up my spine.

My previous code shop maintained a fairly large rails base and we mitigated
that risk by doing as many things "the rails way" as possible, even if it took
more time than some ruby hack.

When you consider how quickly new hires could pick up the project, it easily
outweighed the extra effort designing code in a well-understood format.

------
arocks
This idea might backfire as the non-technical issues can easily mind-boggle an
engineer working on a deep and complex problems.

Leave the meetings and reporting to managers. Some of the best teams I have
worked in have managers who buffer/cushion every trivial externalities from
the rest of the team. This is crucial for the sanity of many developers.

~~~
kevinskii
The key word is "trivial." For significant business needs, engineers can
almost invariably come up with cheaper and better solutions if they don't have
a product manager acting as an information filter.

~~~
hanzq
Both places are nice at times.

My ideal engineering state is heads-down-leave-me-alone. I can write some
awesome code in that place.

At the same time, when a compromise has to be made, I want to know as much
about the problem space as possible.

------
kalupa
I can only think that transparency to a group of intelligent people would be
cause for success. If you hired these individuals to build your product, you
must trust them to be smart people. If you can't trust them to understand your
job by explaining it, you shouldn't be trusting them with coding.

------
josephby
Transparency is an honorable goal in and of itself; that said, most people do
not want to make complex trade-offs, nor do they want to own the unpopular
outcomes of those decisions.

You can expect most people to acknowledge the problem - briefly - and then
return to complaining about your solutions.

------
tingletech
How do you get your project manager to love being lean?

~~~
marcosdumay
You teach lean thinking to his boss. (And make no complains, just teach it.)

------
aklemm
Love this approach, and the same can be done for IT departments. It's the
first step in making IT a strategic resource and not just a utility. Show
technical teams the details of how their work supports the results on the
sales team (and maybe support, etc.) If the manager or executive doesn't
already understand the connection, then this will be an excellent exercise for
them too.

------
colinshark
When I started developing and selling my own product, my obsession on code
quality definitely relaxed. First and foremost, it's now about the end product
and not the code.

It's painful for an engineer to be told to do MORE with less time and less
"quality", but the business cares about more than just code.

