Vittorio Viarengo, VP Oracle Telco Strategy and Development Oracle fusion middleware


Published on

Published in: Business, Technology
1 Comment
1 Like
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Vittorio Viarengo, VP Oracle Telco Strategy and Development Oracle fusion middleware

  1. 1. Vittorio Viarengo Vice President Telco Strategy and Development Oracle Fusion Middleware
  2. 2. <ul><li>The information and statement expressed in this presentation represent Vittorio Viarengo’s own point of view and opinions. They do NOT represent in anyway Oracle’s official position </li></ul>
  3. 3. Benvenuti !!!!
  4. 4. Agenda <ul><li>Oracle Corporation </li></ul><ul><li>Creating Innovative Products </li></ul><ul><ul><li>The Team </li></ul></ul><ul><ul><li>The Vision </li></ul></ul><ul><ul><li>The Process </li></ul></ul><ul><ul><li>The Customers </li></ul></ul><ul><li>Q&A </li></ul>
  5. 5. Creating Innovative Products The IT World Seen from a Simple Baker’s Eyes
  6. 6. The Idea <ul><li>Better be a great Idea – D U H ! </li></ul><ul><li>Idea Sources </li></ul><ul><ul><li>Customer (careful how you listen to customer, they will make you build yesterday products)‏ </li></ul></ul><ul><ul><li>Engineers </li></ul></ul><ul><ul><li>Business People </li></ul></ul><ul><li>Better be mad about something </li></ul><ul><ul><li>Best idea comes from people mad at something </li></ul></ul><ul><li>Better be original </li></ul><ul><ul><li>Only big companies can afford building me-too products </li></ul></ul>
  7. 7. Vision-Goals-Metrics <ul><li>You need a compelling Vision and Mission </li></ul><ul><ul><li>Microsoft: 1 computer on every desktop </li></ul></ul><ul><ul><li>GE: Be n.1 or n.2 in every market we play </li></ul></ul><ul><li>Everybody needs to be behind it </li></ul><ul><ul><li>Agree, disagree… commit </li></ul></ul><ul><ul><li>… but listen to the “bastian contrario” every now and then </li></ul></ul><ul><ul><li>Re-assess the Vision when appropriate </li></ul></ul><ul><ul><li>Vision, culture and metrics fight politics (cook a good cake)‏ </li></ul></ul><ul><li>Set aggressive Goals </li></ul><ul><ul><li>You only get what you ask for </li></ul></ul><ul><ul><li>Belief-action-results </li></ul></ul><ul><li>Constantly Measure Results Against Goals </li></ul><ul><ul><li>If you don’t measure it you don’t know where you are </li></ul></ul>
  8. 8. Manage the Vision, Manage the People <ul><li>Map Individual goals to product and corporate vision </li></ul><ul><ul><li>Makes sure everybody knows what is their contribution to the vision </li></ul></ul><ul><li>Don’t promote Great Engineers to management Positions </li></ul><ul><ul><li>Unless that’s what they want to do </li></ul></ul><ul><li>Know yourself and know the team </li></ul><ul><ul><li>Myers-Briggs test </li></ul></ul><ul><ul><li> </li></ul></ul><ul><li>Establish Measurable goals and personal development plans and review them every 6-12 month </li></ul><ul><ul><li>Measure everybody </li></ul></ul><ul><li>Overcompensate the top performers </li></ul><ul><ul><li>And Routinely Remove the bottom 5% (if applicable)‏ </li></ul></ul>
  9. 9. Embrace Change <ul><li>Change is part of life and it is a known constant of software development </li></ul>
  10. 10. Team - Interview <ul><li>Have a rigorous interview process that everybody knows and follows </li></ul><ul><ul><li>Ask tough programming questions to engineers </li></ul></ul><ul><ul><li>Ask impossible questions </li></ul></ul><ul><ul><ul><li>How many gas stations are in Genova? </li></ul></ul></ul><ul><ul><li>Ask technical questions outside the domain </li></ul></ul><ul><ul><ul><li>Design an elevator </li></ul></ul></ul><ul><li>Make sure all relevant people interview the candidate </li></ul><ul><li>If you have even a single doubt-> NO HIRE </li></ul><ul><li>See people 2-3 times before hiring </li></ul><ul><ul><ul><li>You will see the typical personality patterns emerge after the second meeting </li></ul></ul></ul><ul><li>Take people out to dinner before making the offer </li></ul><ul><ul><ul><li>See how they behave in a social environment </li></ul></ul></ul><ul><li>See </li></ul>
  11. 11. Remember Remember: As hire As, Bs hire Cs
  12. 12. <ul><li>1. Cultivate & reward creativity. 2. Invest in the creative ecosystem. 3. Embrace diversity. 4. Nurture the creatives. 5. Value risk-taking. 6. Be authentic (emphasize uniqueness) 7. Invest in and build on quality of place. 8. Remove barriers to creativity. 9. Take responsibility for change. Development as D.I.Y. 10. Ensure that every person, especially children, has the right to creativity. Become a “Steward of creativity.” * 2003/The Creative 100/Memphis Source: Richard Florida, The Rise of the Creative Class </li></ul>The Memphis Manifesto* Building a Community of Ideas
  13. 13. Kevin Roberts’ Credo <ul><li>1 . Ready. Fire! Aim. 2. If it ain’t broke ... Break it! 3. Hire crazies. 4. Ask dumb questions. 5. Pursue failure. 6. Lead, follow ... or get out of the way! 7. Spread confusion. 8. Ditch your office. 9. Read odd stuff. 10. Avoid moderation ! </li></ul>
  14. 14. Team Composition - General <ul><li>Only Hire As </li></ul><ul><ul><li>An A engineer is 10 to infinite time more productive than a B </li></ul></ul><ul><li>Balance Junior vs. Senior </li></ul><ul><li>Do you have the right DNA? </li></ul><ul><ul><li>If not, go hire or buy a company </li></ul></ul><ul><ul><li>If you are embarking in a product line extension, definitely buy </li></ul></ul><ul><li>You don’t need big teams to change the world </li></ul><ul><ul><li>8-10 developers can write a lot of code </li></ul></ul>
  15. 15. <ul><li>“ The leaders of Great Groups love talent and know where to find it. They revel in the talent of others .” Warren Bennis & Patricia Ward Biederman, Organizing Genius </li></ul>
  16. 16. Why Do I love Freaks? <ul><li>(1) Because when Anything Interesting happens … it was a freak who did it. (Period.) </li></ul><ul><li>(2) Freaks are fun. (Freaks are also a pain.) (Freaks are never boring.) </li></ul><ul><li>(3) We need freaks . Especially in freaky times. (Hint: These are freaky times, for you & me & the CIA & the Army & Avon.) </li></ul><ul><li>(4) A critical mass of freaks-in-our-midst automatically make us-who-are-not-so-freaky at least somewhat more freaky. (Which is a Good Thing in freaky times—see immediately above.) </li></ul><ul><li>(5) Freaks are the only (ONLY) ones who succeed—as in, make it into the history books. </li></ul><ul><li>(6) Freaks keep us from falling into ruts. (If we listen to them.) (We seldom listen to them.) (Which is why most of us—and our organizations—are in ruts. Make that chasms.)‏ </li></ul>
  17. 17. Team Composition - Functions <ul><li>Separate Product Management from Engineering </li></ul><ul><ul><li>Keep PM motivated by customer and business parameters </li></ul></ul><ul><ul><li>Keep engineers motivated by: tough problem to solve, quality, performance, punctuality </li></ul></ul><ul><li>Product Management </li></ul><ul><ul><li>What and why </li></ul></ul><ul><li>Product Design/Program Management </li></ul><ul><ul><li>Responsible for user-centered design </li></ul></ul><ul><li>Engineering </li></ul><ul><ul><li>Responsible for how and how long </li></ul></ul>
  18. 18. PM Team <ul><li>We are responsible for all the user visible aspect of the product </li></ul><ul><ul><li>User-Focused </li></ul></ul><ul><li>Three Main Organizations </li></ul><ul><ul><li>Product Management </li></ul></ul><ul><ul><li>Product Design </li></ul></ul><ul><ul><li>Documentation </li></ul></ul><ul><ul><ul><li>One of the most visible aspects of the product </li></ul></ul></ul><ul><ul><ul><li>Documentation and tutorials </li></ul></ul></ul><ul><ul><ul><li>First User of the product </li></ul></ul></ul><ul><ul><ul><li>Graphic design </li></ul></ul></ul><ul><ul><ul><li>Samples </li></ul></ul></ul><ul><li>1 (PM or PD)/3 Developers </li></ul>
  19. 19. The Product Manager Role <ul><li>The CEO of the product (area)‏ </li></ul><ul><ul><li>Whatever it takes </li></ul></ul><ul><ul><li>The guy who keep everybody a little unhappy </li></ul></ul><ul><ul><li>Define the product as a whole </li></ul></ul><ul><ul><ul><li>Packaging-support-price…. </li></ul></ul></ul><ul><li>Defines the “What” we build and “Why” </li></ul><ul><li>First User of the product </li></ul><ul><li>Outside Customer: The guy who writes the check </li></ul><ul><li>Inside Customers: </li></ul><ul><ul><li>Engineering: Roadmap/Requirements/Cuts </li></ul></ul><ul><ul><li>Marketing: content-positioning </li></ul></ul><ul><ul><li>Sales: pre-sales support </li></ul></ul><ul><ul><li>Channel: Sis/ISVs </li></ul></ul><ul><ul><li>Post-sales escalations </li></ul></ul>
  20. 20. Product Designer (AKA Program Manager) Role <ul><li>Program mgmt resides between development and product management… and customers </li></ul><ul><li>First User of the product </li></ul><ul><li>Customers: </li></ul><ul><ul><li>Outside: the user of the product </li></ul></ul><ul><ul><li>Inside: Engineering- Specs… </li></ul></ul><ul><li>Written product specification </li></ul><ul><ul><li>The PD is responsible for writing down the specification. He/she is not responsible for all ideas and all Specs </li></ul></ul><ul><li>Use Case Implementation </li></ul><ul><ul><li>The PD builds prototypes, implements customers use cases and oversees the &quot;usability test&quot; of the features/interfaces </li></ul></ul><ul><li>Ensure consistent User Experience </li></ul><ul><ul><li>API-UI </li></ul></ul>
  21. 21. Product Designer: Tell Me More <ul><li>File Bugs </li></ul><ul><li>All implementation trade-offs </li></ul><ul><ul><li>Fine-grained trade-offs that impact user visible aspects of the product </li></ul></ul><ul><li>Coordination of the product development groups </li></ul><ul><ul><li>outside product group </li></ul></ul><ul><li>Customer Visits (35%)‏ </li></ul><ul><ul><li>In depth technical product presentations to customer </li></ul></ul><ul><ul><li>Functional Specification validation </li></ul></ul><ul><ul><li>Alpha-Beta validation </li></ul></ul><ul><ul><li>Use case gathering </li></ul></ul>
  22. 22. Engineering <ul><li>Architects </li></ul><ul><ul><li>Who take accountability for the architecture? </li></ul></ul><ul><li>QA </li></ul><ul><ul><li>Depending on the product keep a 1-2 to 2-3 QA/Dev ratio </li></ul></ul><ul><ul><li>Only hire A </li></ul></ul><ul><ul><li>Make QA an engineering problem, avoid delegation </li></ul></ul><ul><li>Performance </li></ul><ul><ul><li>Have performance engineers if you can afford it or make it a developer’s problem </li></ul></ul><ul><ul><li>Measure, measure and measure from the first build on </li></ul></ul><ul><li>Release Management </li></ul><ul><ul><li>Track the details to get the product out the door </li></ul></ul><ul><li>10-1-1 AKA Eat the Dog Food </li></ul><ul><ul><li>Work hard 10 month, take a month off, work one month at a customer site using your product </li></ul></ul>
  23. 23. Process <ul><li>Idea </li></ul><ul><li>Validate the Idea </li></ul><ul><li>High Level PRD (Product Requirement Document)‏ </li></ul><ul><ul><li>Product Management, involve key engineers/architect </li></ul></ul><ul><li>Build Prototype </li></ul><ul><li>Hit the Road </li></ul><ul><ul><li>Validate high level requirements and prototype with customers </li></ul></ul><ul><li>Specifications </li></ul><ul><ul><li>Don’t write single line of code that does not have a deisng note behind it </li></ul></ul><ul><ul><li>Get sign off from Architect, PM and Release manager </li></ul></ul><ul><li>Development </li></ul><ul><ul><li>Adopt and enforce one methodology </li></ul></ul><ul><ul><li>Build everyday </li></ul></ul><ul><ul><li>Punish who breaks the build </li></ul></ul>
  24. 24. Process <ul><li>Development – Continued </li></ul><ul><ul><li>Get to steel thread early </li></ul></ul><ul><ul><li>Short milestones </li></ul></ul><ul><li>Eat the dog food </li></ul><ul><ul><li>Internal application or frequent bug back driven by customer use cases </li></ul></ul><ul><li>Beta </li></ul><ul><ul><li>Ensure somebody will actually use the product in Beta </li></ul></ul><ul><li>Cut, cut, and cut </li></ul><ul><ul><li>Every project will need cuts. The earlier the better. </li></ul></ul><ul><ul><li>PM makes the cut NOT engineering </li></ul></ul><ul><ul><li>Communicate the impact of cut on the business and assess whether you need to postpone the ship date </li></ul></ul><ul><ul><ul><li>The Feature-Quality-Schedule equation </li></ul></ul></ul>
  25. 25. Process <ul><li>Ramp Down </li></ul><ul><ul><li>Carefully triage the bugs daily to see what gets pushed out </li></ul></ul><ul><li>SHIP </li></ul><ul><li>Get drunk and take a week off </li></ul><ul><li>Work on Service Pack 1 </li></ul>