Skip to main content

What makes a great Engineering Organization

Yesterday, one of my friends asked me a very interesting question.  He asked me "How would you define a good Engineering Organization"?.   Both of have spent long years as part of various Software Engineering organizations and hence was very surprised that this question was brought up. We ended up discussing various aspects of a good Engineering Organization for quite some time.

So the idea behind this post to provide my take on  a "Good Engineering Organization" and also to consolidate some aspects that makes a particular organization great.  

caveat: The post is based on my experiences in Software industry, where these kind of Organizations are referred to  by names like "Software Development Organization",  "Product Development Organization",  "Software Engineering Organization", etc.

In my view, the core charter for an Engineering Organization is  "to ship (or deploy) good quality, usable software  in the fastest possible time within the budgeted costs".

The moment I mention this, many questions pop up:
a) What about research and innovation? 
b)What about requirement(s)?
c) Have you thought about scope creep?
d) What about design and process?
e) What about resources?
f) What do you mean by good quality?
g) What about maintainability? etc.

Yes, these are key questions that need to be answered.  But a good organization would  allign the answers to the above mentioned questions in a way that would ensure a good product being shipped in the fastest possible time with reliable quality. The ability to work around the constraints and still meet the core charter would differentiate  of a Good Software Engineering organization from the rest of the crowd.

Next comes the question, on whether there are any key attributes that can be used to identify a Good organization from the others.  My answer would be "Yes", but this is more of a gut feel - as I do not have enough data to validate or refute any of the claims i am about to make below.  The observations comes from my own personal experiences in working with different engineering organizations for significant period of time.

So here goes my list:

a) A clear charter and direction to the team. -   This really helps  because everyone involved knows what to chase and more importantly "what not to chase".   The charter need to be well articulated in a simple sentence.

b) A good set of smart people with a clear purpose - Never underestimate this. Bottom line, this is "people game".  You need to look for a set of smart people who are self motivated to excel as part of the "CORE TEAM".  Once you have it you have crossed the biggest hurdle.

c) Cohesive Team -  The team need to be a cohesive whole, who have free and open communication channel.  They should work in a open culture where there are no secrets hidden behind the closets (or secret projects and agendas). They are willing to help each other out to reach the final objective of realizing the core purpose.

d) Working Iterative Process -  I have seen organization flog this item like crazy. But what helps is to have a simple iterative process which is easy to implement and follow.  The basic idea would be is to get things fast, so that you can check and validate your process.   A good process is one which even the youngest as well as the oldest engineer in the team can follow with minimal effort and can talk about the same with a sense of pride.

e) Standardized tool sets - The organisation should use a standardized set o t tools and development paradigms.  They help ensuring re-usability and leveraging commonality.

Just my thoughtss...

Comments

Popular posts from this blog

Overview of Hadoop Ecosystem

Of late, have been looking into the Big Data space and Hadoop in particular.  When I started looking into it, found that there are so many products and tools related to Haddop.   Using this post summarize my discovery about Hadoop Ecosystem. Hadoop Ecosystem A small overview on each is listed below: Data Collection  - Primary objective of these is to move data into a Hadoop cluster Flume : - Apache Flume is a distributed, reliable, and available system for efficiently collecting, aggregating and moving large amounts of log data from many different sources to a centralized data store. Developed by cloudera and currently being incubated at Apache software foundaton. The details about the same can be found here . Scribe : Scribe is a server for aggregating streaming log data. It is designed to scale to a very large number of nodes and be robust to network and node failures. Dveloped by Facebook and can be found here .  Chuckwa : Chukwa is a Hadoop subproject dev

Big Data: Why Traditional Data warehouses fail?

Over the years, have been involved with few of the data warehousing efforts.   As a concept, I believe that having a functional and active data  ware house is essential for an organization. Data warehouses facilitate easy analysis and help analysts in gathering insights about the business.   But my practical experiences suggest that the reality is far from the expectations. Many of the data warehousing initiatives end up as a high  cost, long gestation projects with questionable end results.   I have spoken to few of my associates who are involved in the area and it appears that  quite a few of them share my view. When I query the users and intended users of the data warehouses, I hear issues like: The system is inflexible and is not able to quickly adapt to changing business needs.  By the time, the changes get implemented on the system, the analytical need for which the changes were introduced is no longer relevant. The implementors of the datawarehouse are always look

Dilbert on Agile Programing

Dilbert on Agile and Extreme Programming -  Picked up from dilbert.com - Scott Adams.