Startup leadership hack: make an opportunities list

My partner James came up with a pretty good idea for opening up more opportunities for career growth at Staq. We call it the "opportunity list": a priority-sorted list of projects that we should be doing, but aren't, because everyone is busy with day-to-day responsibilities.

Opportunities are thing that could potentially be someone's entire job in the future, and would make the company a lot more successful/comfortable in the short-term. Each project is a chance to step up and exercise leadership outside of one's "day job".

Here's an excerpt of the list I just whipped up:

We have similar lists for other departments, so, wanting to set a good example, I picked "contract volley". I'm going to help figure out how to speed up the end of the sales process where specific details of our contracts are negotiated.

My first idea was "let's throw some tech at the problem". I found that there's a whole niche market for contract management software, but none of it looks geared towards a scrappy startup. (I understand why companies do this, but personally if your app has a "Request a Demo" button, I'm gone. I just don't have time to make appointments, and that also implies a much longer onboarding process. Please just let me give you my credit card and start a free trial!)

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