This is the second post in a three-part series by guest writer and Tettra customer, Jason Herndon. The first post in the series lives here and explores how a lack of process and poor knowledge management prevent engineering teams from shipping good code and products. He writes about the role that process plays, how to build robust processes, and specifically what tooling and methods can help your team stay on track.
“This has to be done by the end of April.”
Technical debt is the measurement of how broken you made something while building it. Like taxes and death, it’s a fact of life. There’s no product that gets delivered without technical debt. The best teams in the world master the balance between minimizing how “broken” something is and delivering it to customers.
Perfect is the enemy of delivered.
Years ago, I was on a team that had scoped a project at six months. Early into the project, we learned that it needed to be done in six weeks. It wasn’t a fun six weeks, but we did it. Nights, weekends, rotating shifts, and a near metric ton of coffee, Mountain Dew, and pizza helped us get it done. We delivered it and the client was happy.
I was just beginning my career as a leader in engineering and was shadowing my team lead, (we’ll call him Dan,) when he invited me to join the meeting with management to scope the next project. Dan’s boss stood up and thanked everyone on our team for all of the hard work they had done in order to carry the new product across the line. He then began the next slide with the new body of work that our team had to focus on.
He only got a couple sentences in when Dan stopped him.
“I’m sorry, but we’re not going to be able to do that for another three months”.
Dan wasn’t known as a negative, divisive person. He was engineer number four and was well regarded, so his comment was taken seriously. The CEO leaned forward in her chair and asked why.
“We just spent six weeks breaking things in order to finish this client deadline. We have to take some time to put them back together. Three months, at least.”
The discussion went on for quite a while and eventually got a little heated. The main concern? The work we just delivered brought us in a cool half a million dollars. Not insignificant.
The project we needed to delay by a quarter, (and hopefully not lose altogether,) was worth a few million. That was the day I learned about opportunity cost.
The problem of trade-offs
Opportunity cost refers to the potential gain you lose out on when an alternative path is chosen. Thinking in terms of your opportunity cost can help you realize that saying “Yes” to something means saying “No” to something else. Knowing what you’re saying “No” to is the result of having a well-defined roadmap or backlog for work. Everything is a trade-off.
Every product decision you make and each thing that you decide to focus on means that you’re losing out on something else. Without a groomed backlog or roadmap you simply don’t understand the opportunity cost of each decision that you make in your organization. While you can’t know the future, it’s important to consider what you might be giving up.
Planning years into the future with any sort of accuracy is a Herculean task. However, documenting your roadmaps and goals can help you make the right plans, assess trade-offs, and account for opportunity costs. Your team needs to know (directionally) where you want to be in a year and then (specifically) which quarterly mileposts facilitate progress towards that end point. Nota bene: if you haven’t read “Measure What Matters” by John Doerr it’s a great read.
Your team benefits from clarity and documentation around goals. This could be a roadmap for your product line, a vision for the company, or the backlog for an individual product, (or all three). Return to it every time that you’re making a choice about starting a new piece of work. If a piece of work doesn’t get accomplished by the end of a quarter and bleeds into the next, think about where you wanted to be by the end of that quarter and what the impact to your year could look like.
When thinking about impact, priorities, and tradeoffs when building in a product environment, I take a three-step approach:
First, document a roadmap. Slide decks are often the most useful tool for product roadmaps in terms of how they are presented. However, passing decks around can be a dangerous thing. Quickly, the shared drive file where the Keynote, PowerPoint, or Google Slide decks can become hard to manage. Once a roadmap has gone through revisions, rounds of comments, and becomes the accepted map of “this is where we are going,” I move it into Tettra – even if as a link to the document itself. Tettra + Google Drive = Awesome. A good product roadmap should include a rough definition of sprint milestones. These milestones, if you’re following the OKR methods, should be related directly to your OKRs.
Second, find a project management tool you like and break those milestones down into decomposed sprints. I use Asana to do this, but it could be anything. Follow whatever flavor of Agile suits you best, but be as specific as possible on each individual composed ticket which represents the work to be done, as well as the user stories that signal the completion of your milestones.
Finally, measure the impact of each sprint. Did you accomplish everything you needed to? If not, what work bleeds over into the next sprint? What levers can you pull to still hit your sprint milestones and are your OKRs in danger? This measurement of a report, whether on an individual sprint cycle or at a project level should always live somewhere. Call it a retro, playback, post-mortem or all three … these should live somewhere.
I use Tettra not only as a place to document the roadmap that is to come, but the history of where we’ve been and the trade-offs we’ve had to make. And, as we’ll see in the final part in this series, the playbook for how we get there.