Product Managers: How to get your engineers to love being lean | Hacker News Reader

Product Managers: How to get your engineers to love being lean

blog.kera.io

11 pointshanzq15 comments

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.)

Very well put! Especially about debugging.

Not to mention iterating or doing changes is easier with modular and tested code than with shitty code.

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.

“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.

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.

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.

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.

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.

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.

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.

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.

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

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

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.

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.

Reply on news.ycombinator.com