Always a good time at CTO School. This week was Product-Focused Processes and Resets. I am feeling more and more at these that there's a big divergence in what being a CTO means, and the divide is primarily between big (bureaucratic, politically-fraught) organizations and startups (experimentation, continuous improvement, well-greased wheels). At this and the last one I went to, one of the talks felt like it was preaching to my personal choir, the other felt like it was above my pay grade and beyond my bureaucratic tolerance. Even so, I have found them all consistently interesting. Here are my notes:

---

Cto school notes may 14

/Cto school notes may 14

Malcom Casey: @malcolmcasey from Skillshare

• Process
  • Align product vision and goals
    • Everyone on team is involved
    • Not top down
    • Product planning and prioritization
      • Identify top problems the product is facing or the users are facing
      • 2 weeks
      • Ask why 5 times
      • What does successs look like, how can we measure thay
    • Product sprint
      • Identify owners and milestones
        • This can be a junior person.
        • Doesn't have to be an expert
        • The owner is in charge of just keeping everything on track, not necessarily implementing all of it
        • They call the owners 'zookeepers'
      • Don't micromanage
      • Strategy
      • Product design
      • Implementation & deployment
      • Verification!
        • Make sure after releasing that the hypotheses were validated
        • Decide whether to keep or kill it
      • Meetings
        • Keep them focused
        • Use hip chat/email/etc, get the feedback
        • As soon as they are ready to make a decision, then schedule the meeting
        • Keep the meeting to 15-30 mins
    • Product design
      • Sketching
        • Everyone on team would sketch, come up with a few solutions
        • 3/1 process (cf apple)
        • Come up w 10 solutions, pick the best 3, refine that, pick the best 1
        • After everyone has done this, agreed, likes it, the move on to wireframes, flows, etc
      • Wireframes
      • User stories & flows
      • Product design != ux/ui design
  • Never "launching" always shipping
• Tools
  • Product design
    • Ux/ui.
  • File mgmt
    • Dropbox
  • Product mgmt
    • Trello
    • Google docs
    • Used to use pivotal tracker but it didn't work for then
  • Bug tracking
    • Lighthouse
  • To do list
    • Behance action runner
    • Asana
• Culture principals
  • PayPal mafia (graphic showing how all the early founders went on to start new successes)
  • It's not about making ideas, it's about making ideas happen
  • Creating great team
    • Not about rock stars, about finding a team that meshes well.
  • Over communicate
  • Transparency
    • Tell employees about vc talks, where the company is going, etc
  • Create solutions not problems. Think about how to fix, mot just pointing out problems
  • Ship it
    • Done is better than perfect
  • Startups within startups
  • Set unrealistic deadlines
    • Estimate what you can do, then aim for 1.5x that
  • All new hires sign an agreement that they understand and agree with the culture
  • Simplify and enhance focus
• Focus
  • Finding the most important thing to work on is critical
  • Startups don't starve they drown (in ideas)
  • Focus means saying no to distractions, not saying yes to the one thing (Steve jobs, paraphrased)
• Questions
  • How to get focused?
    • What experiments do you want to run, what can get done in 2 weeks
  • How many hats do ppl wear?
    • 3-4. Helping creative process, (developing), analytics driven (a/b testing), teaching everyone SQL to look at DB, recruiting
  • Does all the shipping cause bad bugs to go live?
    • Baseline testing. Err on shipping first, fixing later
    • They have had critical bugs but they fix quickly, they keep users happy
  • What's the turnover?
    • Haven't had anyone quit. Everyone who has left has been the company's decision
    • Very transparent, strong culture
  • What's the hiring process?
    • Mostly referrals
    • Don't use recruiters
    • Inbounds/branding/team branding
    • Etsy does a good job of this and is an inspiration
    • Very thorough process, multiple phone interviews, homework, meet everyone, check references, keep it within 3 weeks
    • Try to hire for where you want the team to be 12 months from now
  • How many have you let go?
    • About 5 in a year
  • How do you find the balance of too much and too little process?
    • No right answer.
    • Play around with it
  • Any special incentives to keep ppl engaged/motivated?
    • Allow ppl to take as many classes
    • Allow ppl to go in groups of up to 4 and spend company money to do anything they want
    • Give lots of freedom and responsibility

CTO Artsy Daniel Doubrovkine: Pressing the big reset button (@dblockdotorg. Slides).

• How do we feel about resets?
  • It's negative, happens as a consequence of failure
  • Always happens with drama. 'slam the breaks'
  • Compared to changing the wings on a flying airplane
• Examples
  • Exhibit 1 Microsoft windows vista/longhorn
    • Dev began in 2001
    • Very feature-bloated. By 2004 clearly going nowhere
    • Reset in 2004 on top of windows server 2003
    • In 2006 it was released as vista (major failure)
  • Exhibit 2 Microsoft office 98 & netdocs
    • Netdocs was created by microsofties who thought the Internet would kill office
    • Net docs 1 was java, effectively an office reset
    • Net docs 2 reset in C++
    • Net docs 3 reset as a service
    • Spent $500M over the years, 500 devs
• Why do resets happen? Survey of about 2000 reset projects. Data from CTO club in NYC and personal network
  • 4/10: sunk cost kept them from resetting
  • 100% say due to some type of failure
  • 7/10 faced strong opposition to resetting
  • 2/10 blame pure product failure
  • 3/10 blame pure tech failure
  • 2/10 blame ppl failure
  • 3/10 resets led to success
  • 4/10 led to failure
  • 100% of projects that weren't reset failed
• When is it right to reset?
  • always, provided you are 100% sure the project is failing (Ed: tautology?)
  • Find truth-Sayers, trusted ppl who will be honest & help you know if it is really failing
  • Measure how much cost sunk & how much value it is providing
    • Questioner points out: this is the sunk cost fallacy, better to focus on the value
  • Don't be a chicken
    • (chicken & pig committed v involved story)
    • Only those that are committed should decide
  • It can be a smart career move to make the hard choice
  • Can be very dumb career move if you fail or the organization doesn't support you in the reset after you hit the button
• How to reset
  • Act now, decisively
  • Invest in trust capital
    • Have to compromise in order to gain trust. For every year of trust capital you have a about a month to burn when in a reset
    • Build it by helping others achieve their goals
  • Double or nothing
  • Split execute
  • Under promise & over deliver
    • Audience points out: this is the exact opposite of Malcolm Casey's strategy
• Aftermath of a reset
  • People forget very quickly how bad it was
  • Don't expe t to be glorified afterward. This is just part of your job
  • Making decisions about when/where to continue dev paths is always part of your job
  • Foster a culture of frequent but smaller resets
    • Experiment often
    • If things are posed as experiments, and you let devs try their ideas, you will keep evolving (Ed: and they will be happy)
  • Stop at the top
    • When you're at the top, don't get comfortable...try resetting then to make it even better
      • Ed: wha?!
• Questions
  • How is the data calibrated?
    • (audience grumbling/saying 'let him speak')
    • Somewhat anecdotal
  • How does that affect the code base?
    • Depends, not necessarily software/code (e.g., could be purchased CRM software, when to throw in towel?)
  • When ppl from the outside advocate reset, it's not good. Is that a personal opinion or from the data?
  • How do you connect the concept of reset to tech debt?
    • They are well connected. I don't like working in environments where you need to explicitly pull out tech debt. That should go without saying
  • I pivot on market more than on technology. When you pivoted/reset the tech/rewrote did you get the founders to buy in too?
    • Yes, that is critical, also critical to show that it is promising quickly