CTO School Session 1: Being the Tech Leader
I went to CTO School Session 1 on Monday night. Charlie O'Donnell interviewed Mark Uhrmacher, CTO of Ideeli. I was in the back of the room and couldn't hear all that well but I used FreeMind to make a mindmap of what I did hear. These are my notes:
- + -
hiring
- distributed ok
- timeshift
- mumbai, canada, ukraine, us, spain etc
- look for people who can think at all levels of stack
- ask lots of technical questions fast and furious
- distributed ok
- + -
key technology decisions
- chose Rails (early on)
- max dev productivity
- no time to rewrite
- two modes: what sticks? and omg it's working
- chose Rails (early on)
- + -
dev methodology
- 2-week sprints
- keeps QA in sync w/out drifting
- no religious philosophy
- 2-week sprints
- + -
biz-minded CEOs who don't understand tech
- how to provide visibility to non-technical CEO?
- agile methodology helps b/c short timeframes
- short timeframes: less deviation b/w biz side and tech realization
- have to appreciate you have a better understanding of the tech
- set expectations and beat them slightly
- if someone asks for the impossible, say it's impossible
- be transparent
- "share your risk"
- here's what at stake
- here are the tradeoffs
- becomes join risk/decision
- engineers have a tendency to want to please
- keep that in check
- you are managing for shareholder value
- "share your risk"
- being the best technologist is not a requirement for a CTO
- communication is the key thing
- + -
how does structure of org change over time?
- QA:
- outsourced in phillipines, india
- never as automated as he would like
- they do full regression tests
- product manager
- hired at 10 people
- while rebuilding UI
- actually needed someone w/ good proJECT mgmt skills to corral different aspects
- outsourced, distributed dev team
- program mgmt becomes more important
- program v product v project
- program: set of projects. mixture of product and project
- requirements gathering, feature definition, herding cats
- program mgmt becomes more important
- QA:
- + -
any conflict about who is managing developers? (product v cto v ?)
- did not happen
- could happen where people are more naive about dev process
- + -
at what point did developers become managers?
- first dev became manager, was doing both, started to flame out
- hired head of development to replace him, moved him to architecture manager
- organization truck number:
- how many people have to get hit by a truck before you are dead in the water?
- + -
how much do you think about developing roles?
- cool think about growth companies is they are ruthlessly merit-driven
- lots of room at the top
- if your skills exceed your years, this is the place to be
- no need to "pay your dues"
- + -
how do you find a peer group of other managers?
- there is a CTO club in nyc
- range from technical people to great managers
- there is a CTO club in nyc
- + -
characteristics of good hires
- curiosity
- thinking at multiple levels
- initial impression of NYC dev market was people were looking to fill particular roles/niches
- but doesn't think that's a good thing
- need people who can adapt to changing roles/products/technologies as opposed to experts in one particular one
- + -
how do you manage communicaton w/ distributed time
- skype
- mingle (thoughtworks product), didn't scale past 20 devs
- now use jira
- card tracking/bug tracking
- added confluence for wiki (recently)
- most dev and ops guys live in skype
- and in card tracking tool
- IM
- long-lived dev chatrooms
- it's a tough environment to write code in
- very obvious who is phoning it in
- + -
any formal processes to keep in touch aside from ticket tracking?
- daily scrum call (they have to shift time to get on that call)
- break into smaller groups as opposed to all 70 devs on one call
- daily scrum calls keep things working
- + -
how did they manage outsourced QA, making sure they had a test plan etc?
- for regression tests, for every bug they'd automate a test or put in their plan
- work from the same user stories used to develop features
- for critical functionality, or something subtle, program managers would write out test cases
- now they have product managers do further user acceptance test
- + -
growth period
- 15% month-on-month growth last 40 months
- just keeping the wheels on the train is a challenge
- things that are annoying now become unmitigated distasters in 180 days if not handled well
- 15% month-on-month growth last 40 months
- + -
big advantage of distributed team
- they can fix problems overnight
- interesting: much higher productivity from developers who are not in the office
- offices are distracting
- corporate culture is very interrupt-driven
- + -
how do you measure productivity?
- "how full is the parking lot at 6pm" -- fairly standard metric (in SV)
- cards are either getting done, or not getting done
- look at your 2-week sprints...what is getting done?
- + -
how do you balance time to market v code quality? (esp when you are small, starting up)
you WANT to get a product to market
willing to incur tech debt to get there
the hope is you get large enough that eventually you can get a "team B" who can pay down tech debt in parallel w/ new features
12-24% of SW development bandwidth goes to refactoring
- + -
what is the value YOU personally contribute now to your company?
- worried about org structure
- how good are they at getting thigns done? (features, bug counts, happy customers?)
- is there a better way to organize?
- continuous improvement model
- Am I putting pieces in place to ensure future success?
- if it's too hard for devs to figure out what to build, bring in product person
- worried about org structure
- + -
how do you build trust and recruit developers internationally?
- finding people who knew rails was hard
- in NYC mostly impossible
- had to look elsewhere
- building trust: spent many hours w/ open skype sessions...like sitting next to him
- finding people who knew rails was hard
-
Charley Miller
-
patelc75
-
bantic
