The rise of Entrepreneurial Engineers

 

I often use the sentence – Good engineers build things; great engineers build valuable things. But the idea of value is abstract, what might be valuable to one person may not be valuable to another. But it is not so, when it comes to profitable organizations. Here ultimately it should end up – in contributing to organization value while complying all governance checks. I have seen engineering colleagues wondering if we should worry about all this. May be 5 years back the answer would have been not necessary, but now it’s necessary. The rise of Entrepreneurial Engineers is like what we observed with rise of Citizen Data Scientist, but also the other way around. The idea is, though this engineering team still works with the Business Owners and Product owner & management team, they have skin in the game of what gets build. They understand business priorities and are driven towards solving customer problem and adding business values. They are aware how to apply their engineering mindset to solve impactful problem using sustainable solutions. 

With teams I work with, it is something we continuously work towards. Some of the steps, I work towards with my team, and I can recommend are:

Before adopting any feature, we try to ask ourselves:

1.  How will this feature add value?
2. What will happen if we don’t adopt this feature?
3.  How is this problem currently addressed?
4. Can we find out the financial impact & Return on Investment on this feature?

All this can be documented under different artifacts like – CONOPS document, Value document, User story etc. 

Teams I work with, with experience, we have discovered, learned, and created a process of continuous – conversation & collaboration. It is a cycle of continuous conversation with other stake holders. Some of the check points we have developed over the years, are - 

1. Do an internal tech team analysis – feasibility, compatibility & valuation analysis
2. Present understanding, POC or plan to business leaders, owners & SMEs.
3. Broader Technology team peer presentation
4. Discussion with vendor to clarify assumptions, if required
5. Discuss with enterprise architects how this piece will interact with overall architecture
6. Then start the implementation

But there may be scenarios, where, before being able to do any of this, you might need to have an MVP in place before you can have any discussion. This strategy is extremely useful when the overall team is not too sure, building what would be valuable. Its when, all the stakeholders, see a tangible MVP in front of them, they start to share improvement ideas. In most new product development lifecycles, first few features, are developed like this, until the process matures.

In the last decade with more engineers in board rooms than ever, this new breed of entrepreneurial engineers will be a significant player in the organizational vision & roadmap. The organizations which will thrive & grow, will need to have 2 things:

·         Superior product-market fitment

·         And a good product - Design & Architecture

 

Organizations should put a lot of focus in these two areas. Once these two are in place, it enables the Sales & Marketing team to effectively do theirs. Organizations & teams should be very aware that all operation & enabling process should be focused around improving these 2 areas. Once a solid foundation of these is in place, Customer relationship & Delivery should take care of themselves.