Skip to content

Starting and Managing a Software Company

paradigm shift in software development

  • speaker: Eric Lazarus
  • abstract
    • Paradigm Shift Software Development (PSSD) is designed to integrate well into the popular software development methodologies such as RUP and Agile and augment them in areas that they are often silent.
    • If you plan to lead a small or large technology intuitive, from building a cool interactive website to managing R&D for a large technology company, this talk will provide practical insight about how to do the work better and produce more powerful technology solutions.
  • bio : AI research / tools -> building 'impossible' => 'can't fail
    • background and passion for philosophy
    • architect for jp morgan, ibm, etc
    • developed reports of security of voting
    • investigator on NSF contract with NIST
  • background
    • Eric Lazarus has been building and deploying complex and innovative computer systems for some of American’s leading companies including IBM, Prudential, JP Morgan Chase, mega-manufactures including GM and Unilever and mega-retailers including SuperValu for more than 25 years. He has managed R&D activities for such organizations as Stanford University and the National Science Foundation. In this talk he will explain the key insights he has had that has lead him to codifying an unusual and powerful approach to developing innovative technologies in a reliable and dependable way. In this talk he will introduce such ideas as Radical Respectfulness, an approach that encourages managers to give something that costs nothing and get something in return that is priceless: An increased commitment to project success multiplied by the willingness to engage far greater creative energy. He will also discuss the technique called Power Questions which allows you, as a technology manager, to identify issues and opportunities early and use the resources of your entire team and personal network to address them.
  • paradigm shift in software development
    • early insight, just starting out, high tech start up, project in trouble, consultant just wasted time

"meta-empowerment"

  • meta-empowerment was clear lesson - if have managers need to empower them to let those managed understand work
  • reasons for project failure: misunderstanding of requirements, risks, lack of commitment to clear vision of success, missing skills or key resources, most methods do not focus enough on reason for failure
    • one common lack of info: why is budget important, why first version needed for os Z?
    • manager may put goal in risk but can't find this requirement unless it's explicitly stated
    • often business side will try to push all requirements at once... but need to only specify a few points that they can optimize
  • first principles of PSSD
    • radical respectfulness - person who devices "clever" technique that saves project may not be from expected source
    • paradigm shift is possible at each level - think of new alternatives at each step in the process; typically might just be innovation during design, but should be always
    • participative - doer decides
    • it is role of leader to provide vision to project - don't really focus on 'vision'
      • not all visions equal - "fitness goal" vs. "athletic goal" - athletic goal could be much more powerful
      • motivating, energizing, powerful, charismatic
      • calls all to 'step-up-to-the-place'
  • what is vision
    • job is ... consider visions, pick some, articulate vision

radical respectfulness

  • collaborate with 'product management' not be slaves
  • programmers as 'replaceable parts' - circle nouns
    • hire very carefully
    • invest in mentoring, building specific skills needed in near term
  • be/express confidence that your team can ID risks
    • work with your team to mitigate risks
  • challenge: cant use all ideas, so what then? DBT - dialect-able behavioral therapy
    • range of minor empathy to all society understands -- give most validation possible without mistruth

decision matrix (DM)

  • used in extended groups... - performance, scale, cost, etc. with a weighting factor
    • deeper understanding of project can come from questions and considerations from team
    • options that can be critical to a breakthrough can come from anywhere
    • taking part in developing DM goes far to help people engage in a process
  • how is this helpful?
    • have objective evaluation because agreed upon, decisions aren't made in haste, i.e. without emotion
    • explore space of options: goals/values, options, understand intersection --- anything else is a guess
    • reducing friction - makes manager a peer in the group (requirements are in charge, not manager)
    • covers all assumptions of everyone - may allow non-highest score operation to win
  • when should they be used...
    • answer not obvious, goals are not obvious
    • get participation when - you will be able to use information, overhead is acceptable
    • DO NOT use it if decision should not be left to others
  • method is applicable
    • design decisions, hiring decisions
    • requirement decisions (what features should be in release)
    • architecture
    • risk mitigation
      • no other known project definitions seem to define the risk, probabilities, and results of failures
    • being open to revising DM as assume set of values is essential
  • job as project executive is ....
    • now clearly defined by goals in DM
    • allows you to know the limits of meta-knowledge - "knowledge of knowledge" (wisdom)
      • example: expert in inventory system didn't understand how it would change with perishables (food)

second principles of PSSD

  • possible to have shift at every stage, preparing to have one is enormously beneficial
  • how to do it
    • ask key questions - meta questions - inspire people to question
    • affirm input, reward it, give credit liberally, renaming it
    • expect it - insight is RIGHT HERE
    • provide CONTEXT
    • hire for it, empower for it
    • openness to tools, techniques, approaches, question assumptions
  • questions (power question examples)
    • how will this project be deemed successful?
    • how can we make you "very happy" that meets all requirements but not happy?
  • challenges that will be faced
    • inertia - people used to projects in a specific way
      • make a 'role model' from the audience and show this as an example, more powerful if just you do it
      • reward all acts of initiative (reward pigeon getting close to ball, then you can reward after playing it)
    • lack of meta-knowledge (don't know that lack of knowledge is here)
      • ask impertinent questions -- ask 'stupid' questions about why people do certain things
      • highlight insights - point out your own wrong assumption (also good to debug arrogance on your part)
    • belief that "i can't make a difference in org of this size"
      • disprove and highlight
    • creating resentment / making enemies - might be perceived as criticizing
      • focus on positive both of old way and new; cheerful and give credit

questions

  • how to remove expectation from business side because another can be at risk?
    • show 'risk' matrix to business side that was created with developers to show more goals are reached
  • have a list of tools or skills that are standard before hand?
    • start out with use cases (description of features to build) then think about tech to use
  • how do you know that you have all of the needed columns in DM?
    • allow team to change it, if you can work it out that others have contributed will make them more confident
    • example: working on insurance company as architecture consultant, at first seemed okay, but asked insurance people how will you know if it succeeds? this process took a long time to find the simple answer... if an incoming call could be completely diagnosed in one call it was good
  • asking if schedule can be done in 2 months, would it hope to show it done in 1 month
    • similar example is just asking if 'life depended on it' what would it take to exceed expectations

technology project discussion

software problem - voice to voice translation

  • idea: translate spoken english into another language - Schmidt says it will be next big thing
    • voice recognition has high error rate
    • server-based translation may not be available, what about on client itself
    • need natural language translation
      • need to be able to learn online to do translation
      • 'out of sight out of mind' <= russian-english double => 'invisible insanity'; 'mind was wiling but flesh was weak' <=> 'vodka was good but meat had spoiled'
  • prototype partially developed already by CU graduate developers
  • problems
    • identify the market - institutional versus consumer
      • largest market is buisiness travelers and tourists
    • how to communicate with market
      • 'mail order bride' where you incentivize use with partial sales
    • hard to work with people from diverse - some suggest facebook approach
  • questions: niche market that is cheap to communicate with but advertisers care a lot and want to ad to them - try to approximate profit with these
    • in startups if you can identify a small niche, that might be good enough
    • example: starting a vitamin company, targeting students (hard to communicate with students), but "nero-enhancer" seemed to help people doing power-lifting "body quicken"
  • what is the meta question we should ask?
    • is gov't question reasonable? UN has need for "get the gist" quality of translation
    • need to clearly define level of functionality and technical challenges
      • i.e. need to show them in feedback as well

commentary and links

Post a Comment

Your email is never published nor shared. Required fields are marked *
*
*
CAPTCHA Image
*