Shampa Banerjee spoke on the topic: Thinking Strategically – A Survival Skill for Today’s Technical Lenders to Engineering Leadership SIG, SVForum on 21st June.
She began by saying “Let’s have a conversation” and asked about what challenged Technical Leaders the most in their work place. The audience homed in on the intrinsic tussle between Engineering and Sales. Sales made promises about new product features and got the commissions while Engineering took on the responsibility to deliver those promised features and toiled for long hours, every day.
Then, Shampa mentioned her experience as a technical leader in several companies, from startups to the big ones. Matrix Management upon acquisition by a bigger company brought in successive changes. The changes began showing results when Product Management was eventually made to report to the Technology VP. This led to engineers questioning what they were developing, rather than developing to requirements: “Would I use what I am developing?”
She highlighted a current trend. More than CIO’s or CTO’s, it is Sales and Marketing, who are introducing the use of relevant Social Networking tools in their companies. What then, is the role of Technical Leaders in a rapidly evolving landscape? How do they position themselves in the company’s business strategy of selling their products, services to customers?
The audience began to enunciate various scenarios that challenged them, adding what changes were needed to produce the desired results. Here are some instances shared by the audience:
- Technology leader took control of the product roadmap. As a result, prioritizing and scheduling engineering effort to match promises made to customers became relatively easy.
- In a Professional Services Group, the Account Manager and the Technical Expert were competent possessing excellent leadership skills. One of them was made a leader, though both were accountable for success. Their collaborative efforts brought success. As the business expanded, each was paired with a junior from the other side to facilitate succession. Ensuring the sharing of responsibility for success between the two functions was very instrumental in instilling collaboration.
- In a medical devices company, it was necessary to get the Specifications Writer and the Specification Requirements Consumer to be synchronized. One Product Manager was assigned for every 10 engineers. Audience was polled for what might be a good ratio. The consensus was that independent of the ratio, Product Management and Engineering needed a tight collaboration, in tight alignment, for product success.
- Writing requirements requires (pun unintended) the specification of requirements without mentioning implementation or solution. In a particular company, Product Management and the Development leader collaborated in analyzing the initial list of requirements and rewriting them independent of implementation. The list shrank to one third the initial size making it easier for Development to scope effort and timelines.
- Even in some organizations that use iterative, rapid processes, a Business Analyst negotiates between Engineering and Customers. The success hinges solely in how well collaboration is ensured by executive management.
The audience resoundingly favored the need for Product Management to work closely with engineers. Challenges are the scale of work and time zone.
Shampa displayed a high level approximation of the traditional model of an Engineering Team as a two dimensional matrix based on skill sets. The horizontal axis denotes Technical Capabilities while the vertical axis denotes Process Orientation.
1. Top Right Quadrant: Functions of VP, Engineering
2. Bottom Right Quadrant: CTO, Chief Architect
3. Top Left Quadrant: Program Managers
4. Bottom Left Quadrant: Customers? (drew audience laughter)
Questions were raised about this model:
- Where is innovation?
- Where is business acumen?
The Audience commented that the above two should also be added as additional dimensions to the above model in today’s competitive market.
Shampa chimed in that Technology leaders need to be aware of this as they are not only responsible for the success of their technology but also for the success of the business. The Technology leader can provide inputs to the business and needs to be part of business decisions. Technology leaders need to be a partner with Sales and work together on decisions that impact engineering effort.
Success of a company is not just Technology. What else is required? Shampa presented a slide that compared “Where we are” and “Where we should be”.
These were presented as two adjacent lists, as follows:
WE ARE HERE WE SHOULD BE HERE
Technology as a strategy Business strategy (offer technology options)
Participate in Sales Partner with Sales (educate as required)
Partnership Discussions (due diligence stage) Co-drive Partnership Decisions (take a stake)
Influence Product Roadmap Co-Own the Product Roadmap
Fund Raising (not the driver) Fund Raising: Lead vs tech discussions only
Build vs Buy Decisions Build vs Buy: Help define business priorities
An example was provided of a large manufacturing company that asked for 15 different things. Engineering empowered Sales to negotiate with the customer. This resulted in 5 requirements only.
The Audience now offered their experience in how the two sides can engage the customer.
· Have 2 lists: Can-Do and Cannot-Do maintained by Engineering and shared with Sales.
· Engineering collaboration with Sales and vice versa can be ensured with suitable incentive structures that hold both responsible for success. The typical model of Sales being paid a commission upon Contract Signing and Engineering paid full time to deliver much later is rife with opportunity for misaligned goals.
· Product Management, as a representative of Engineering, accompanies Sales to size up promised features. Before a deal is signed, the Product Manager needs to have a say. Externally customer facing and internally working closely with engineering the product manager is the liaison, a conduit to ensure that what is promised can be delivered (in scope, time and with allocated resources).
· Startups don’t have the luxury of affording Product Managers. The CEO plays the role of Product Management. Sometimes, this role may not be the right fit. Executive training (retraining too) is recommended in such situations, as is done in larger and more mature companies.
· Engineering Technology Leaders need to be honest and be vocal with Executive Management.
· What can be done to pre-empt failures? Share everything with the people early-on. Schedule periodic meetings to track concerns and address issues quickly. Decisions are logged. If the road hasn’t changed the decision stays.
· A comment made from a User Experience testing group drew laughter: Avoid listening only to the hippo (to the highest paid person). Ask if we are doing the hippo thing now.
Shampa summarized the audience feedback above as follows: that outcomes really depend on personalities. Often a failure is due to the people and not due to the technology / technical solution. As an example, while the CEO decides what needs to be done, she recommends that a Technology Executive be part of the Executive Fundraising Team rather than just computing the cost, number of development hires, and delivery timelines.
What are the essential ingredients of a Technology Leader?
- Need to be a great Communicator: not only in verbal and written skills but also in Body Language
- Need to be approachable. If the leader is seemingly distant, people will be afraid to ask, discuss and share
- Need to redefine / reframe the problem. Albert Einstein said: “You cannot solve a problem from the same consciousness that created it. You must learn to see the world anew”.
- Need to be a community builder
- Need to have an eye to anticipate (every one today is a visionary and can be)
It is paramount in current times for a Technology Leader to be an all-rounder; with 360 degree skills to be approached and accepted.
Kennedy said: “Some men (person) see things as they are and ask “why?”. I dream of things that never were and ask “why not?” The new technology leader rephrases “Biz is Business” with “Passion is Business”. This person needs to be in tune with breaking news, to retrain, to accept change by expanding and adapting oneself. Collaboration is a necessity; i.e. work with a common goal where each owns up for success. Note that Operations as a big team (that we knew) is gone now. It is only a handful of people.
Shampa emphasized the need for New Company Structures and Incentives that can ensure collaboration and sharing of responsibility for success in the business. Examples:
- Large companies can work as several small fleets and behave like startups.
- Have open discussions: Should everyone have a share in the sales commission? Do we incentivize the right behavior? Abolish hierarchy?
- The book “In search of Excellence” was mentioned. Even in large companies, smaller teams were given big incentives and allowed to use the resources of the large company. Eg. Skunkworks.
The Audience responded how a very large company in our area worked as a large number of small teams as if each one was a startup. Two years ago, they found this strategy was not working favorably.
Shampa concluded that big or small, companies need to revise incentives and control structure in order to ensure that
- Customer facing Sales&Marketing and Producing folks in Engineering Work together
- Both own delivery (i.e. a well-defined common success is identified)
Ravi Ganesan has over 20 years of experience in Product and Engineering Management. As General Manager of TIBCO India, he was responsible for all fiscal and operations planning. He hired dozens of engineers, coordinated with external organizations and set up processes and procedures for development, facilities, finance, IT, release, support, and travel. Similarly, as a Senior Director in Adapter Engineering, TIBCO he was responsible for product management and engineering execution for over 25 adapter product lines (about 15% of company revenue). He has proven himself to be highly effective at Program and Process Management. He was responsible for the day-to-day management of two off-shore contracting companies in India, with a total of close to 100 employees. Among the areas for which he was responsible: setting product requirements and specifications; on-time delivery; budget management; designing SLAs and performance metrics; and coordinating and communicating with other organizations (marketing, sales, alliance contracts, legal, release, etc.).