The Blue Rocket Manifesto: Build
Products & Teams
Blue Rocket has built dozens of products for startups and companies looking to expand their software product portfolio. Every one of our customers eventually wants our help to transition to an internal team.
Want a fast start on your project, but don’t want to keep an expensive contract team around for years? Here’s what’s worked for our customers.
- We start by helping our customer recruit the right internal people.
- As new internal team members join our customer, we embed them in our team.
- We coach them and teach them and eventually they outnumber us, and we’re embedded in their team.
- Then, when the internal team is self-sufficient, we disappear.
Recruiting
- Recruit the right people early in their career.
- Embed them in a team with experienced members.
- Assembling an experienced team takes a year and a half. If you don’t already have one, we provide starter yeast.
- They will grow quickly into experts.
Team structure
Blue Rocket projects start with a project manager, a lead developer and a junior-to-mid-level developer. Usually the project manager and the lead developer are around for most of the arc of our participation in the project.
On-the-job coaching
We help recruit your first or next developer, usually more of a junior level. We embed them in the team and we coach them: our process has built-in coaching: We teach the team to break down tasks into day-sized chunks and we teach them to create a work plan for each day. Each day, the team reviews all the code that’s produced that day. The review of the work plan gives the team a nice touch point to help the new developers plan their day and how they’ll tackle the task. The code review gives the team a chance to give and receive immediate direct feedback on what can change about how they executed the task to make it even better. That combination is remarkably fast in bringing people up to a very productive level of execution ability.
Two-week sprints
Classically we’ve used two-week sprints because it gives us a cadence where each sprint is short enough that we can predict what’s going to happen inside those two weeks. But each sprint is long enough that at the retrospective, we have plenty to talk about. Two-week sprints have worked well for us but we’ve been experimenting lately with continuous Kanban style work on similar projects. It’s a little early yet to know which we like better and we’re still keeping the two-week retro cadence even in that.
Daily rituals
We work with user stories, and very few user stories are accomplished in a day. So we take a user story apart and split it into day-sized tasks. We’ve developed a canonical list of task types. It may be laying out a screen. It may be implementing a gesture. It may be implementing the call to the backend for a dataset. We purposely make these small so that we can always accomplish it in a day — sometimes we’ll get more than one of them done in a day. Sometimes we’ll get one and a half or two done. We can pretty always count on getting one of them done, and that gives us fodder for the cadence of: plan → work →review → test, rinse and repeat.
Plan, work, review, test
This cadence creates a very reliable throughput for the team. It also gives many people on the team the chance to see each unit of work and offer feedback — so that it’s not just one person in a silo who comes back down from the mountain after two weeks and everybody’s dismayed by what he’s produced because it wasn’t what they expected or wanted. We have this constant feedback that lets us adjust on the fly and push it through the team so it meets everyone’s expectations.
Recruiting for culture
We’re not focused on tools. Especially when we are recruiting junior developers or QA trainees. We aren’t worrying about: “Are you good at JavaScript or are you good at react? Are you good at Swift?” It’s too early in their career for that to matter. What we focus on:
1.Self-motivated
“Are you self-motivated, whatever the technology? Have you already built something on your own?” It’s a must-have for people who want to be developers.
2. Teachable
“How teachable are you?” I always include a lot of questions in interviews that relate to mistakes they have made, what lessons they learned from it, and how would they handle it differently today? If they won’t admit to a mistake, then then they won’t allow me to correct that mistake, right? I need them to have that humility, to be able to reference concrete examples where they made a mistake and how they fixed it, or how they would do it differently today to fix it.
3. Curious
Curiosity is non-negotiable. Curiosity is an engine that pulls the train for a lot of our work. If you’re not curious, then you’re not going to have that spark that leads you to explore and figure out the answer to the problem. Our days are just filled with problems. As a developer or as a QA specialist or as a designer, they are here to learn the constraints of this problem and create a solution that addresses it. So that curiosity is non-negotiable. This has been really successful as a filter.
Apprentice as QA
With these three things, people are ready to start as QA trainees. And as soon as they start knocking QA out of the park — which they all have so far — then we’re ready to start offering them development tasks. Or if they’re more drawn to some other area, maybe they’re showing a flair for organization and we want them to help the project manager as an assistant or a project manager trainee. But in any case, it’s proven to be a really successful combination of traits, and people make rapid progress in the first year.
