Sunday, May 20, 2012

Business over Engineering

This post is a retrospection of a simple concept for managers, but something new engineers tend to struggle with.  I include myself in that group when I recall being a fresh graduate and ready to do things the best possible and try saving the world.. (but I never got the cool flying cape).

Early in my career I struggled with the problem of:
Business > Engineering (business over engineering).

I think this is a very common problem for most technical oriented people.  Why?  Because they know the in & out requirements to solve the problem, but not always have the best resources or scenarios to give it an "engineering solution".  They only know business is pressuring and that causes to deliver a "non-optimal" solution.  :(

I remember this struggle kept me asking WHY?..  Why can't I deliver a "perfect" solution?...

For me to understand this, I had to understand the Business problems.

That's when I realize:
Sales > Business (sales over business).
In order to have business, we need sales.  Why?  Because sales is what makes the $$$ money we all need.  But shouldn't it be Business > Sales because we sell "our businesses".  The reality is NO!  If there is a Sale to make $$$ profits, we will make our business to tap there.

This gets us to pretty much the top of the chain:
Customer > Sales (customer over sales)

Ever heard the expression "the customer has the reason"?  Well, they are the ones $$$ paying after all.  So what the Customer wants is what Sales will try to fit and pitch in for getting the contracts made.  And if an engineer needs to jump through hoops to get there, "they better".

So in summary the chain of business can be summarized as:
Customer > Sales > Business > Engineering

Of course this is a super simplified version of how things work, and devil is on the details of how the actual chain executes.  But it's important for managers to communicate well with their team and get them in the real context of how things work.

Personally I think the key is in identifying where the real engineering is required and separate it from the softer business requirements.  That way your team can focus in building a better core and avoid over engineering functionalities which tend to be more flexible.

No comments:

Post a Comment