Notes from DC CTO summit

I really enjoyed the recent DC CTO summit. The talks were informative and there were so many of Baltimore-based CTOs that it also functioned as a Baltimore tech leadership networking event!

Here are some quick notes I took on things I want to tell my Staq colleagues about. There was a lot of other good stuff; this is me focusing on the things that apply to our company at this moment in history.

• Joshua Szmajda showed off a really impressive use of a whiteboard for kanban. I think informal, analogue-based systems like this could make a huge difference in our team's ability to self-manage, just from being able to better visualize what projects are in progress and when they get stalled.
• Joshua cited the kanban book Lean from the Trenches which sounds good. An audience member recommended kanbanery.com for an online version of the whiteboard.
• Quote: "Working software is the only metric"
• A speaker cited unpublished but credible-sounding research showing that around the world, some software teams can complete the same project 50 times faster than others. 
• Paul Barry pointed out to me that this doesn't mean that those "50X" teams are better at all facets of software development; all we know is they were 50X better at this one particular task.
• Reminds me of Derek Sivers's advice on how to hire programmers
• Edward Kim gave a great talk called "Hats are the new management", describing how he distributed small but important manager jobs to each member of his team. 
• One job we definitely could use is "Bugs Captain": a person who monitors a Bugs chat room and ensures a first responder is assigned, and monitors the quality of the response. I definitely want to stand up a separate Bugs chat room.
• Another job: rotating responsibility each week for manual QA. Edward's team forward-deploys someone from the dev organization to help the QA testers each week. Good way to get to know all parts of an app.
• They have a dev blog hosted on medium - supervised by a person wearing the "Blog master hat"
• It reminded me of how the Navy divvies up collateral duties: there's a whole separate structure within each chain of command to take care of all kinds of jobs that aren't formally part of a Sailor's billet.
• Paul Barry recommended using Optimizely for A/B testing, and encouraged us to use A/B testing as a devops tool: use it to measure the impact of new features by rolling them out to subgroups of users
• He also recommended using "canary" tools such as measuring the exit rate of certain pages: can help you find out when a certain group of users is having problems with a certain page
• Andrew Montalenti presented an inside look at the daily routines of the parsely remote team. I like the idea of syncing every developer to a familiar weekly rhythm
• Start the day with a #standup chat message explaining what you're planning to work on
• End the day with a #sitdown message explaining what you accomplished, what you're stuck on
• Monday: bug fixing and planning day
• Tuesday: 30 minute (virtual) staff meeting to kick off the week
• Tuesday noon through Friday noon: uninterrupted flow time. No meetings. All coding.
• Friday at noon: demo time
• Friday afternoon: tie up loose ends
• No weekend work / rest and recover