A Schedule that Changes with You

I was 20 when I worked at my first startup during my sophomore year. It was 1999 and I felt lucky to be working with a group of people my age (and younger) at a hot tech startup. I regularly slept on the floor of my office to be there more in case something needed attention; some people upped the ante and bought futons; most of the time we spent around the office in whatever clothes happened to be there. I once worked a 46 hour stretch to solve a blocking problem for the team, and that was only just above average. It was a valuable experience that taught me a lot about myself and what I was capable of.

Fast forward 13 years and now I'm in my early 30's, a veteran of several startups in the Bay Area (including one of my own), in serious relationship, and have a cat (living the dream). I have a great group of friends and am often the pivot for bringing everyone together. The idea of sleeping on my office floor doesn't have that same charm as it did in my early 20's. My girlfriend works market hours (EST), which means she's out of the house by 5:00 every morning and asleep by 9:30 pm. I still love working with small teams, mostly at startups, still spend nights researching technology and software development or trying to understand business markets and how to spot opportunities at the intersection of technology and un-met demand.

I think many of us who work in technology eventually start to feel the pull of conflicting responsibilities. As we get older we build our network of friends, commit to more serious relationships, and take on more and more responsibilities in our community. We start to think about our health, deeper motivations, evaluating our legacy, looking forward to the future, and wondering what larger impact we can make. How do we begin to balance all of these parts of our lives to remain productive and fulfill all of these other commitments we've made to others?

People talk a lot about "hacking" our personal lives these days, so I penciled in a few hours by myself and sat down to think about productivity, schedules, and time management. I spent a lot of time making notes not just on my own schedule, but also a cross section of people I regularly interact with; single, married, with / without children, employed / unemployed, etc. I came up with a list of all the things that I know about how they manage their personal and professional lives and fed it back through the lens of my own. I identified the times when I'm most productive (mornings) when I'm the least (afternoon, post lunch), and when I need time to socialize and recharge (evenings). I also factor in my alone time, which for me often means more work (by choice). What I came up with is my schedule for sanity, listed below.

• 8:00am - 9:00am: Coffee, breakfast, reading blogs/articles/email, starting to explore work that needs to get done for the day
• 9:00am - 12:00pm: At the office, circling up with the team, starting to get work done for the day
• 12:00pm - 1:00pm: To the gym for a workout. My afternoons are when I slump the most, and this almost guarantees short-circuiting that unproductive block
• 1:00pm - 6:00pm: Afternoon work, sometimes meetings, sometimes going heads down, sometimes fleeing the office
• 6:00pm - 9:30pm: Recharging time. This can mean dinner with the friends, going climbing, finding something fun going on in the city, or just being domestic. I try to put aside all thoughts of work here to really get the most out of it and be ready for my time later on
• 9:30pm - 10:00pm: Futzing around, maybe just reading the internet, maybe playing a game, etc.
• 10:00pm - 1:00am: Back to work. Here's where I'm starting to dig deep into bigger problems. I'm often at the whiteboard in my home office during the time sketching ideas, or turning those into something tangible. Last night, for instance, I spent fixing someone else's library so I could make progress on a project that needed it.
• 1:00am - 7:00am: Sleep time. Sometimes I go to bed earlier depending on my mood and energy levels, but this is a good average

BTW, this isn't a prescriptive formula, it's just what works for me. I want it to be a call for you to think deeply about how you can are really productive and to spend some time re-evaluating an almost 200-year old idea of labor.

Practical Talk: Between Product & Engineering

Something important to me as an engineer when working with product managers is that he or she can really wrap their head around what they want to build and clearly explain it using as much detail as is sufficient and necessary to start delivering functionality. Ambiguity is a major driver of frustration and resentment between these two key players within an organization and contributes to a lot of wasted time, money, and creativity. It's a skill to think through what features are key to a deliverable, capturing the details, and sticking to that list when working with engineers. It takes commitment to wanting to deliver the product with quality and good time while maintaining a positive team atmosphere. A common pitfall that I have seen over and over on teams is a product manager who comes up with an idea, throws it over the fence to engineering, and upon receiving a schedule proceeds to move on to other tasks for a month without regular engagement with the team to talk about how they can contribute to quality or timeliness. I have observed a direct logarithmic relationship between the engagement between these two parties and the success of most software projects. The key for the product manager is to find the point where the graph of interaction levels off and work with the team at that level and no more. Unfortunately it is all too common that this point is never reached.

On the other side, engineers (like myself) often have a way of looking at a problem, reducing it to a simple solution that handles the case put directly in front of them, and then offering a timeline with some padding duly added based on previous experience. We go on implementing our well designed systems, everything plays together well, perhaps we've beaten our timeline by 10% - 15%, and we are happy. What usually happens next is the product manager comes back and says "This is all great, but our users need to do X, Y, and Z with the product, and can we also add this feature before the deadline because it would be great". Welcome to the brick wall at the end of the road to elegant system design. Suddenly design decisions you thought made sense are a roadblock to delivering features and you're scrambling to rethink ideas you threw away previously.

Is there anyone here to blame? I don't think so. I think both sides laid out their plans, and then went off to work on them in isolation from each other, not considering that there was a deeper story to be told on the other side. Product managers don't often capture all the use cases because they haven't gotten their hands on anything to close their feedback loop. Engineers are implementing what they were told to, without any notion that it may not be delivering any actual value to customers because they only had a narrow, temporal view of the product.

This isn't an uncommon scenario, so does that mean it merely reflects a core tenet of software development? I don't think so. It's not difficult to come up with a reasonable solution after thinking about it a bit, but like learning to solve a Rubik's cube not everyone is willing to put in the time and effort to start climbing the learning curve.

To start, I suggest we start to turn stories (requirements) into a living contract between product managers and engineers. Contractually, they ask the product manager to commit to a specific slice of functionality. Alive because both sides accept that as deliverables are evaluated by the product manager, new functionality may emerge that displaces less important functionality. For their part, engineers should commit to two practices: edge-to-edge development and delivering entire slices of functionality.

Edge-to-edge development means when delivering a feature, how and where it's deployed, necessary infrastructure such as logging, monitoring, and instrumentation, and a way for it to be tested from the perspective of the customer are all in place. This requires more up-front effort before delivering the first feature, but the marginal cost of adding new ones falls quickly. Developing entire slices of functionality thinking about the system less as discrete parts and more as a vertical profile of all the parts working together to develop a feature to the customer. Instead of working on any particular piece (such as a backend system) in isolation and then trying to layer other clients on top of it (such as a web UI or a data feed generation system), each with their own functional requirements, survey the system as a whole and then pick a whole slice from the bottom up to a customer deliverable and build that. In doing so many of the assumptions from both the product and engineering sides can be validated or challenged as appropriate, and the deliverables can begin to converge on a the product your customers need.