Time Is Money: Managing Software Development At A Fast Growing Startup
“You know what would be AWESOME?? If we could put a cat here, here, aaaand maybe over there by the company logo.”
As a web developer at a rapidly growing startup, you get a lot of crazy requests. Some are going to make your product better, some are more drops in the “Yep, that didn’t work” bucket. Ultimately, you only have so much time, how do you decide what to build?
Or more accurately, how do you inform your leadership team, sales team, and everybody else how much it will cost in terms of time and resources to build out product X so that they can make the call of whether it should be built. That of course includes opportunity cost; what critical features are you not building in order to increase the product’s cat quotient.
Having a strong idea of the cost of an experiment can help in deciding whether or not to take on the risk of that experiment. And let’s face it, every task taken on at a startup is an experiment. Just take a look at our arduino powered coffee machine.
When faced with the question of how to convey the cost of a ticket to someone higher up, we had several options. We needed something that would grab people’s’ attention, inform them quickly, and not slow us down. So we kept it simple: cold hard cash. How much $ per hour will this task cost the team?
Sprinting to the finish line
We are not the first agile software development team to ask how they are going to prioritize projects. Nearly every dev team has to consider two factors – implementation efficiency and communication with stakeholders on other teams.
A common approach is to use the value-complexity matrix. Picture a graph. On the y axis, you have business value ranging from low to high. On the x axis, you have implementation complexity, also ranging from low to high.
This approach is desirable in terms of its simplicity. If a task is highly complex and has low business value, it should be avoided. If it is not very complex and has high value, it moves to the top of the queue. But there is an enormous grey area here. For example, business value is a vague concept. Does the feature respond to current, potential or churned customers? Each of those are valuable to different teams (customer success, marketing, and sales respectively).
Additionally, implementation complexity is a bit vague. Does this refer to an amount of time, or number of engineers required? Is it complex in terms of the number of steps required to complete? If so, will completion of steps 1-4 provide some benefit, while steps 5-10 can be completed later? Or do all 10 steps have to be completed before value is realized?
In another quadrant-based system I’ve heard of, each quadrant represents an element of prioritization of a particular sprint task:
Q1 – Time to build
Q2 – Level of customer need
Q3 – Priority for a particular team (either sales, marketing…etc…)
Q4 – Technical complexity
Each quadrant is ranked from 1 to 4, and then tallied. The higher the total number, the higher it moves on the sprint and the order of release.
This system works quite well, since it takes into account all stakeholders; the customer, the nontechnical team member, and the dev team. But this is not ideal for us since it is counter to our company value of Keep Things Simple. So we chose a different route…
Attributing dollars makes sense
Whenever we have a new product or tweak to be made, we estimate the dev time to complete it and then multiply that hour amount by $50 (a round rate that’s close to the cost of an hour of dev time in terms of salary). We place this number right in the title of the (Trello/Github/Gitlab/Jira) ticket so that those who are looking at our queues and deciding what should be a priority can make an informed decision. Things get moved, re-sorted, and sometimes thrown out by the leadership team. This helps us stay lean and quick.
Sometimes tickets require work from both a backend and frontend developer. In that case we might break up the “cost” into two numbers. For example:
$50b + $2000f – Party Scheduler
$50b and $2000f are the backend and frontend developer’s quotes respectively. In total, this ticket would mean $2050 for a party scheduler. Which begs the question, do we really need a party scheduler?
Each developer quotes their own work, so these numbers help the CTO as well. From these estimates, the CTO can say, “That seems like a lot of front end work. Maybe we should rethink this build.”
Efficiency and accountability
Of course, nobody is tied to these quotes. Holding people to their quotes seems too strict for the goal at hand; create estimates that help guide decision making. And come on, we’re engineers, not lawyers. (No offense to any lawyers who represent or will represent 15Five (“Company”) or its employees (“Employees”) now or at any point in the future.)
What is useful, is to have a debrief at the end of every sprint to discuss how close we came to these estimates. Engineering leads should be doing this anyway, if for no other reason than to increase accountability and efficiency on the team. The added bonus is that as the team become more accurate with these estimates, stakeholders from other teams will be able to communicate expectations about the product roadmap to customers and other employees.
So how has this strategy helped us?
1) It helps us make decisions about what is a priority.
2) When loading on work for a sprint, a developer can have a sense of how much work they can accomplish in a sprint and only pull in say $2000 worth of tickets for that sprint.
3) Finally, we can calculate how much work got done in the past sprint and give leadership and our investors an idea of our velocity; how much dev is putting out each week/month/quarter. Sprinkle in a little regex parsing of the title (magic geek speak for looking for a word or two like “bug” or “fix” in the title) to determine if the ticket is a feature or a bug. Now you have a comparison of how much time you’re devoting to each category.
In March of 2016, we unveiled our Plus and Pro plans along with a suite of new features including metrics questions and visual dashboards. In Q4 we released a complex new feature called Objectives (OKRs). Releasing so many new features and product changes over a short span of time was one of the most ambitious engineering projects we have ever attempted. We could not have completed them without an efficient system to estimate and prioritize our software development efforts.
At the end of the day (or sprint cycle), attributing dollar amounts to projects is a nice little hack that lets us prioritize what gets done, what doesn’t, and by when. This process keeps cross-team functionality high, relationships healthy, and our customers happy. Unless of course they want to put a digital fidget spinner in the middle of the UI. That’s where I draw the line.
Paul is a Senior Software Engineer at 15Five, a lightweight weekly check-in that delivers a full suite of integrated tools – including continuous employee feedback, OKRs, pulse surveys, one-on-one meeting agendas, and peer recognition. Paul has over a decade of teaching and improvisation experience and is a core engineer on 15Five’s integrations, deployment, and product teams.
