ASAP is the Default Deadline & Other Startup Reflections
Reflections from my time at Ascend
Reading Time: 7 minutes
If the measure of any job is the ratio of time spent to amount learned, my time at Ascend ranks among the highest. Below are key lessons I’ve learned in three months as an engineer at a 30 person, 1.5 year old startup.
1) ASAP is the Default Deadline
of a similar flavor to Speed Matters and Be Impatient but intended for new grads/interns.
In EECS 376 at the University of Michigan, the majority of the students started the week’s problem set the night before it was due. This was understandable — after all, you didn’t get any brownie points for completing the assignment before Wednesday at 8 pm.
But, it’s not just that college doesn’t reward students for completing assignments early, it’s that there’s always a predictable finish line – a letter grade on your transcript at the end of the semester.
This draws a stark comparison to startups, where there is no “finish line”. Once you hit a milestone, it’s immediately time to reach for the next one. There’s always more customers to acquire & markets to tackle – it’s why Uber, a rideshare company, moved into the food delivery space.
When there is no finish line, the game completely changes. It’s not about getting to the finish line – it’s about who can get the furthest. The faster we go, the further we can go.
At Ascend we have “deadlines” but these are largely for planning & external purposes (i.e. we can tell our B2B customers when certain features will be released) but internally, the deadline is ASAP.
Assume the deadline is ASAP & move fast.
2) To wear many hats, take ownership.
“The opportunity to wear many hats” is frequently cited by prospective startup employees when asked why they chose to join. The only way to effectively do this is by taking ownership.
When I think of someone wearing many hats, two images come to mind.
One is a man who in an effort to take on many roles, ends up with a hodgepodge of different responsibilities. One day, he’s writing a sales script, the next conducting competitive research – in addition to his main responsibilities as an engineer. Unfortunately, he likely spread himself thin.
Second is a man who took ownership of a project from start to finish. Tasked with building an admin dashboard, he talked to users to understand if the solution fit the problem, shipped the dashboard, and synced with marketing on the right copy. Along the way, he wore many hats as a PM, engineer, marketer & more.
Aside from the personal growth resulting from taking on many roles, the benefits of taking ownership are clear:
In a world where doing any one thing exceptionally well takes your undivided attention, working on tasks all connected to the same project reduces the need to context switch.
By taking the project from 0->1, you know all the complexities surrounding this feature, and as a result are in the best position to 10x it.
I do believe an exception exists for recruiting. Recruiting the right people is so critical to the success of the startup that it’s everyone’s responsibility to constantly be recruiting, regardless of whether or not their other roles tie in closely with it.
3) Build your own filter to determine which ideas are low vs high leverage.
At some point, you’ll want to pitch an idea that, from your perspective, is massively beneficial to the company. You’ll fight to get buy-in from the team and secure the time & resources to execute on the idea.
In reality this idea is good, but it’s low leverage. There are more important tasks to be prioritized.
The tendency to believe you must execute on your “great” (but in reality low leverage) is even more likely early on in your career for two reasons:
Inexperience means you haven’t developed an effective internal weeder to determine which ideas are high or low leverage.
The youthful desire to prove yourself combined with the ‘prize’ (i.e. a return offer, a promotion, further trust in you from higher-ups, or a raise) riding on your ability to see something through from 0->1
A good litmus test to not fall for the ‘all my good ideas are worth pursuing’ fallacy is by asking yourself:
If I successfully take this idea from 0->1, do I see the company as a whole or myself benefitting more?
If the answer is the latter – the idea belongs in the backlog.
Smaller lessons
(‘smaller’ measured by how much screen space they take up, not by importance)
The details are everything.
While the last 1% of any project might only seem like the small things, this last 1% matters as much as the first 99%.
Ask for help early.
You might think that if you ask for help, you’ll appear dumb. But, appearing dumb is better than appearing slow. The longer you wait to ask for help, the longer it takes to finish the work & as a result, the slower you appear.
There’s a balance to strike here between figuring it out yourself & asking for help – I’m still figuring that out. If you have thoughts, I would love to hear them!
Domain Specific Lessons
Quick wins are crucial when onboarding new hires
At Ascend, we have a tag in Linear called ‘Quick Win’. Every new hire starts off their first day with a ‘Quick Win’ PR – the entire point being to give new hires the momentum to confidently take on larger projects.
I’d even take this a step further and say even experienced employees should pick up ‘quick wins’ every once in a while – when progress is slow or between projects.
Engineering wise, over- abstraction can be worse than duplication
The classic example of ‘doing things that don't scale’ is Doordash’s founders manually completing delivery orders. When the time came to build a product around this, they already deeply understood the complexities of food delivery.
A similar lesson applies to programming — If you abstract too early, not only is it unnecessary & unreadable, but you may run the risk of building the wrong abstraction.
As described in Repeat Yourself, Do More Than One Thing, and Rewrite Everything,
The problem with always using an abstraction is that you’re preemptively guessing which parts of the codebase need to change together. “Don’t Repeat Yourself” will lead to a rigid, tightly coupled mess of code. Repeating yourself is the best way to discover which abstractions, if any, you actually need.
The alternative to abstraction – duplicating code — doesn’t scale but initially, it can be’s one of your best bets.
A Final Note & Further Reading
Disclaimer: As usual, things are easier said than done – I’m still working on putting them into practice. On my best days, it’s a work in progress & a failure on the worst.
I’d love to hear from you! Do you agree or disagree? Does something not make sense? You can drop me a line at dheera.vuppala@gmail.com or leave comments on this blog in its public Google Docs form here.
Special thanks to the Ascend team & specifically to Eddie, from whom I’ve learned many of these lessons and for his seemingly never-ending patience & to Ernesto for being the walking representation of ‘ASAP is the default deadline’.
If you’re interested in learning more about Ascend, check out the links below!
An overview of what Ascend is doing & the opportunity in front of us.
The bird’s eye view of the B2B Payments Space & where Ascend fits into it.
And if I haven’t already hyperlinked enough blog posts, here’s a few that inspired this one: