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.).
No comments:
Post a Comment