Keys to a Successful Scaleup Engagement Start at D.Labs
D.Labs has “startup” (eg. MVP) type initial engagements and “scale-up” initial engagements. This latter scale type initial engagement can have two forms:
- Where we replace the existing team, or
- Where we work in synchronization with the existing technical team.
The following applies to special considerations when applying to that “type 2” / “add scaling” type engagement. This section is both an internal operations guide and an external customer expectation guide for that purpose.
3+ Week on-site engagement
- Understand the meaning of keywords in context (eg. “tested”) and processes (two sprints)
- Build informal social connections and mutual respect
- Understand the larger environment & tool+dev stack
- Use customer’s stacks & processes initially to reduce communication risk between the two companies.
Two people at first
- At least one must be a D.Labs influencer and have intimate knowledge of D.Labs processes, skills, and abilities
- Formal knowledge transfer and checklist
- Both must be productive as soon as possible.
- Team players who can transfer knowledge and build offsite teams around.
- Enough social skills and/or
- Either embedded into existing teams or a semi-autonomous feature development work is better than other more complex tasks that might be later.
- Enough challenge to test people & processes, but no so much risk to jeopardize entire engagement.
- Clear support process on customer side: buy-in, process, escalation…
- Needs to be queued up before completion of first work so no gaps
- Increasing complexity, value, scale, and interdependence … stepwise incremental.
Other Key Success Factors
- Define what “type” of transition:
- Optimize for minimal impact — inefficiency on our side ok. Eg. reverse engineering vs a training program by the customer. or,
- Optimize for shortest time to velocity– sacrifice internal team’s immediate capacity to bring on the new team faster. Eg. formal training, documentation, pair programming… or,
- Balanced for overall efficiency — some impact to existing team’s velocity and a natural ramp of the new team.
- Must balance short-term contribution (tactical, short-term) and long-term autonomy with scale (strategic, long-term) at all times. One must never dominate the other.
- Assuming capacity scaling is the goal, must have vendor involvement in all key bottleneck areas.
- While all IPR is always owned by the customer, there is other knowledge accumulation. There must be an intentional plan to decide when and how this flows back to the customer’s team. Ie. Efficiency / speed vs redundancy/risk choices.
Enjoyed reading the article? Hit that clap button 👏 and help others find it.
Have any question, you are building your own product (or/and company) or just want to connect? Drop me an email on firstname.lastname@example.org I’ll be happy to help.