Startup vs Scaleup
If you have been enticed into reading this by our scary pumpkin then congrats for getting this far, and we will assume nothing about who you may be and start right back from the beginning briefly by defining what the differences between a Startup and Scaleup are. Best done in a handy table;
| Startups | Scaleups |
|---|---|
| Validating a product or idea has a market fit by most efficient means possible | Has an established market fit, and needs to evolve its offering to compete for more market share |
| Team makeup will mean you hired specific people i.e. software engineers, business development, sales and operational staff, but they will probably be doing more than one role. You yourself may be a whole board wrapped up into one, CEO, COO, CPO, CMO & CTO. | Your team makeup and scale of business will already mean you have hired a middle layer, and some more senior team members enabling a focus on growth, whilst continuing to run the day to day. Team members will stick more closely to their designated role |
| Risk appetite, in the early days, is high, you have little of the market cornered, you are happy to risk or pivot to meet those growth targets, in order to get that foothold in the market. | Scaleups, have traction, a customer base, repeating revenues, they are more risk averse. Their investors and team members alike expect progress to multiply revenues and successes alike. So big risks are harder to take, harder for the board to agree too, harder to get the team to buy in to. |
| Operationally the team members who are responsible for things outside of their main job i.e. those picking up the middle layer need systems in place to deal with marketing, recruitment, HR, product development & delivery. These systems will be very loose, and the team members will have a great deal of autonomy in selecting and making something work, hindered only maybe by cost, and getting others to use them | In a scaleup operational systems have to be easily repeatable, efficient, add real business value and be cost effective. So it is likely that these systems may evolve or change a great deal as you move from Startup to Scaleup phases |
| Management hierarchy : little if any, usually founders remain heavily involved. | Management hierarchy : start to hire professional managers, corp experience, greater risk of issues as responsibility devolved, allows the founders to focus on company growth rather than day to day |
Hopefully the above outlines some of the things we feel defines a business in Startup vs a Scaleup phase, and they resonate with the founders of businesses at both phases. The point of the blog was to talk about why we value milestones so much when helping businesses scale, so let’s get to it.
For any business to successfully scale it needs a business strategy in place, seems pretty obvious, right? The work any technical teams do should underpin that strategy. The basis for all your milestones should loop back to the following question; does your technical strategy underpin and enable the delivery of your business' growth strategy?
If it does, and that is a big question, and one for another blog, you need real expertise to break that into a high level milestone delivery plan, a meaningful one that provides easy to understand milestones that the team & business can easily see the value in. People struggle to work to goals, if they don’t truly understand and value what went into creating the milestone they are delivering against.
Scary concept, yes it is ok, and you should measure your teams performance as you scale!
It’ll give investors, team members, & customers alike confidence if the product or service provided improves regularly. If there is a blip in the road then it is an early warning system, a way to find out what to correct and how urgently.
Milestones bring some order to things, if you think about Startup businesses and their ways of working, by necessity it can be fairly chaotic, in a small team often those who shout loudest will take priority when it comes to getting “stuff” done. In a Scaleup it shouldn’t be that way, there are usually more teams, their voices often carry the same weight, and they are all competing for the same pool of stretched development resources. In the Scaleup landscape a small but structured plan with key milestones outlined, gives the dev team focus, making their work more efficient, and gives the wider company and teams visibility on technical evolution. This is vital as it will allow other teams to plan their own work and aspirations around what can really be delivered by the technical team with a visible plan to refer to.
Milestones should be directly related to a strategy element, so the dev team can break that down into deliverable chunks, the completeness or breadth of the features required to deliver on that strategy are under the control of the business and team.
The most important point about milestones for Scaleups is they cannot be used as a means to brow beat, punish a team or people within the organisation. If used this way, they will fail to be used and adopted.
So what is a milestone;
milestone : noun
- a stone set up beside a road to mark the distance in miles to a particular place.
- a significant stage or event in the development of something.
For our purposes the second definition fits quite neatly in delivery of technical solutions, below is an example of how a milestone may look or be defined and planned by a team.
Hopefully the above makes clear the level that milestones should be defined at and planned for in terms of delivery. The work to deliver the above milestones would cover multiple sprints, or delivery iterations, so delivery of story points shouldn’t matter to senior leaders as long as the overall milestones remain on track. The milestones above are unambiguous, and they are measurable in most cases. They are clearly linked to a strategic business goal, in this case to achieve 100,000 new registrations per month. How do your plans, or milestone plans look compared to this? Are they clear to you, do you get value from your plans, do you have confidence in your plans delivering? If not, why not? Are they too low level for you to understand? Give these questions some thought, and read on.
Milestones vs Story Points
It can be all too easy to fall into the trap of exclusively measuring sprint success and story points as a gauge of how effective or efficient a delivery is, and by that stick how successful a technology team is at delivering the required output to underpin the business strategy. Perhaps an alternative way to think about this is about winning a battle vs winning a war. You may have a number of sprints to deliver a milestone, some of those sprints may be successful, some may not. Teams often fall into the trap of losing sight of the real measure of success, how are you tracking against milestones and ultimately against the growth targets set in the business strategy. Now we are not saying there is not a place for sprints and story points, they can help structure immediate work, prevent distractions and help a team get into a repeatable rhythm.
Remember: Performance should be measured against deliverables, features & outcomes, for the love of all things halloween not story point
Milestones are great for other reasons, they are usually agreed as part of an inception process for technology teams, basically the whole team figures out and agrees at a high level what will be delivered and by when roughly. It is important here to point out that this is not Waterfall in disguise. The technical breadth and depth of what is being delivered can change based on available resources & time available for delivery, strictly with the agreement of the business of course. It can work just the same for business teams. The important point here is the team is part of this process, they create the output, and by default should be bought into it and personally invested in delivering it to a good outcome for the business. It is also a very tangible measure of success. Milestones are far easier to alter than a full replan done in a traditional way, this is because they are far more easily understood by everyone than fully detailed, unrealistic highly detailed plans.
Summary & Conclusion:
Getting milestones correct takes practice, they are worth the investment, and lead to better outcomes, happier teams and ultimately a more efficient use of resources & funding. They shouldn't be as scary as halloween, and should be a lot less scary than old school planning and metrics for everyone involved.
Key Takeaways:
- Business strategy must be underpinned by technology strategy, from that milestones can be derived
- As a member of a senior leadership team, remember to pull up, story points should mean nothing to you, nor should you care, it may be a tool your teams use to add structure to their delivery.
- Ensure your milestones are meaningful and can be linked to specifics in your business strategy, you should be able to easily talk your team through what each milestone is and what its achievement means for the business.
- Milestones should be easily measured in terms of what success looks like, there should be very little ambiguity. Don’t be the leader that leaves gotchas in milestones, so teams become demotivated by missing out on success over trivial things.
- Empower your team to deliver milestones, empowerment & accountability are great motivators for teams
Summarising all the above we would suggest that if your teams are delivering a milestone plan, and the big things are on that plan, then you should have far fewer big problems in your business & teams than if you micromanage every aspect of delivery and progress.
How are you creating plans now? Are they milestones or are they something else? Has this given you pause for thought? Why not give us a call for a chat about what you have read.
Read here about how we helped a couple of Manchester based Scaleups on their journey ArcticShores / UNSHACKLED. Finally if you are interested in discussing how we can help Scaleup your business anywhere in the world, but especially in Manchester then please do contact us.
“Not only was the 60i team able to practically help us meet our goals, but they brought with them a shared sense of pride in what we were building, great collaboration, and a great work ethic too.” - Safe Hammad - ArcticShores - CTO
“60i were instrumental in the success in bringing to market a new proposition at enterprise scale. Bringing with them a wealth of experience not only in complex technology and programme delivery but in leadership; capable of managing complex programmes, stakeholders and driving change.” - Andrew Santus - UNSHACKLED - CTO
