I joined Nuvo when there were 3 people, including two co-founders. So I want to write about what I have done in the past two and half years, mostly for myself, so I can remember what I did and for what reasons I did certain things. And most of these things are going to be non-technical, a lot of processes and structures.
And I am NOT here to argue all of these are optimal solutions. These are simply things we did and I believe they worked well enough for me to say they are worth mentioning.
The first thing I set up at Nuvo was interviewing process. The process as whole is very standard - founder chat, onsite, technical loop, behavioral loop, etc. Nothing out of the ordinary. But the one thing I want to highlight was the debrief. I took a page from Amazon's debrief process, which is - seeking a plan that everybody can get behind instead of seeking consensus.
In practice, we run 6 steps below.
Here I am going to focus on the step 2 to 4.
Nobody (talking about the candidates) is perfect and everybody (talking about the interviewers) sees things from different perspectives. So it's important to hear the good things and the bad things from all the loops before casting a vote. And of course in most cases, you are not going to get a consensus loop. If the votes are mostly not inclined, then it's pretty straightforward - mostly a not inclined decisions. But for mostly good kind of voting situation, then the next step is to try to address the cons and see if the team can come up with a plan for the candidate improve in the lacking areas. And depending on the area that's not meeting the bar, the plan is going to vary quite a lot.
For example, let's say the candidate is not good at frontend development. The questions then should be something like below
Sometimes, after asking these questions, the answer is no. But sometimes, you could come to the conclusion "We know the candidate is lacking in ... areas, but we are willing to take the risk to extend the offer because we believe the candidate can improve fast enough, with the coaching and guidance from the team."
So at the end of the debrief, the whole debrief crew understands the risk and has an actionable plan once the candidate gets onboard.
The gist is "Getting to a plan that everybody on the team can get behind instead of getting to a consensus".
The next thing I set up at Nuvo is the oncall process. This actually took a while for everybody to get onboard, and for good reasons. As a startup, we are always bandwidth constrained, meaning every bit of engineering bandwidth we can get is important. To argue "we want somebody to be oncall and not do feature development" is a hard task.
The one situation that really pushed us to start thinking about this was actually after we got the first batch of AEs, getting the sales process more in place. With fast iterations of feature releases and improvements, we found our sales team constantly asking engineering team about product specs or engineering support. Depending on personal working relationships and ownerships of projects/features, we found those questions coming to random engineers. That basically means any engineers could get random questions at random time and the engineer has to context switch to move the deals.
Because context switching is such a costly activity, we realized we need a process to help protect MOST engineers bandwidth so they can be heads down on the bigger chuck of work they need to get done.
And that's how we crafted the first iteration of our oncall process. Very different from a traditional big tech oncall process, our first version of oncall responsibility includes below things
With this first version, we did manage to achieve below things
Of course with the company functions getting more mature, sales team getting better, customer success function getting set up, our oncall process evolved quite a bit. But that's how we started the oncall process and it did help us survive the time when engineers need to wear more hats on a daily basis.
The next major process I pushed for and set up at Nuvo was sprints. For a long time, we didn't have any formal protocol on how engineering products were planned and executed. And that was okay for quite some time because the priority was clear - we got many fundamental pieces we need to put in place to get the product off the ground.
However, once we got to the place the fundamental pieces are completed and we were focusing on revenue expansion, we found ourselves always scrambling to try to hit the targeted date.
One of the problems for this issue was visibility bi-directionally between sales and engineering team. In one direction, engineering team does not really know what and when things will come down the pipe from sales side, thus causing re-prioritization of projects, causing frictions. In the other direction, sales team doesn't really have visibility into what engineering team is working on and ETA of all those projects they care about to close deals.
In order to solve this problem, we agreed we need something in place for give visibility both ways. That was when I decided I was not going to re-invent the wheel, but rather tweaking some things I have seen before to make it work for us. So I proposed running sprints.
Admittedly, sprints, or really any sort of project management methodology, when pushed to the extreme, is going to be absurd. For sprints, I have seen a lot of "creating/closing tickets for the sake of creating/closing tickets", and sometimes that inflates what's really getting done, twisting the reality. That was NOT what I needed. However, used to be a participant and a lead of many sprints with different team, there was one thing I really dig - the sprint meetings. More specifically, the backlog grooming, the sprint retro and the sprint planning meeting.
And those three meetings were the key parts of my proposal. The backlog grooming meeting started a bi-weekly motion of collecting, evaluating and prioritizing requests/asks generated from sales side. The retro and planning (back to back at the end of a 2-week sprint) gives engineering team a chance to consistently look back at why things were missed and look ahead two weeks to understand what needs to be done and in what order. The existence of sprint functions as a metronome, also starting guiding other daily operations within the company to get in place. On top of that, the sprint board is the one centralized place for anyone who needs to know what's being worked on, and who's working on what. And this visibility is given to everyone in the company, not just the sales team.
So that's why there are quotes around the word sprints in the title of this section - we did not start running sprints for velocity estimation or for rapid development. We started because of the structure it provides for engineering team and everyone around it. Later on the team did start to run sprints more formally - adding in capacity planning and tracking completion rate.
To end this part, I want to re-emphasize that this is not a tutorial or anything like that. This is simply me feeling the need to track these thought process I had when I set up those things. And up til today (10/15/2024), these three things I mentioned above are still the three main processes we run consistently.