6 Time Sink Hazards You Only Learn Through Experience
Why Delays Happen in Startups and How to Mitigate Their Impact
Startup environments are exciting and high-urgency, but with the fun of delivering a new product, comes the weight and consequences of delays.
Scheduling tasks accurately is essential and as pressure increases, the impact of not keeping to the schedule grows larger too. In startups it is important to be aware of timeline hazards, particularly when moving at such a fast pace.
As painful as forecasting potential delays can be, it will be the difference between a product being launched successfully or not at all.
Today’s article is for managers of small teams building physical products and engineers entering startups for the first time where we will cover:
What each time sink involves
Examples of scenarios which cause the greatest delays
How to manage the risks of delays
New Starters
While working on IBM’s OS/360, Fred Brooks observed that adding personnel to a project that was already behind delays it even further.
He wrote a series of essays on it which became published as the book “The Mythical Man Month” in 1975.
The book for me was essential reading and I’ve experienced several examples of delays brought about by new starters (including myself).
It is important to note that bringing new people into a project should not be seen as a negative, but the management of onboarding should be carefully carried out for all people’s benefit.
Examples
Setup taking longer than expected (e.g. with toolchains that will be covered later)
Potential mistakes due to misunderstandings and lack of documentation in a small fast-paced team
Managing Risks
Allocate enough time for new starters to get up to speed
Ensure there is regular dialogue about how are they are getting on
Maintain an environment of strong documentation, or at the very least strong communication with people who own different parts of the work
If building physical products, bring new starters into tasks that involve being hands-on (such as assembly) to accelerate their understanding of the product
Some of these suggestions may seem obvious, but I have experienced great examples of managers who have brought me into teams and in my opinion it is critical to a project.
Toolchain Setup
A toolchain is a set of tools (including a development environment) that developers and engineers use to build your technology.
Setting up a toolchain can take longer than originally accounted for, as the setup involves building a system of different tools that need to work compatibly with each other.
Examples
New starters entering the project
Consultancies handing over work to be managed internally
Toolchains requiring updates (if operating systems no longer support them)
Managing Risks
Ensure toolchain setup processes are documented comprehensively
Making sure toolchain setup tutorials are made part of consultancy handover meeting agendas, either remotely on a call or in-person if possible
Ensuring team members working on toolchain related tasks are given as much support as they need
I went more into detail about why toolchains can be larger time sinks than originally accounted for, and how to manage them in Hardware and Firmware Toolchains Simplified for Business Managers.
Consultancy Handover
The handover of technical work from consultancies to your internal team for them to manage will be one of the biggest risks of delays.
The risks come from technical work being migrated from one team to another.
Examples
The consultancy tested their technical work on their computers and toolchains (as mentioned before) and therefore may have missed bugs that are only experienced on the internal team’s systems.
Parts of the setup process may be very obvious to the consultancy who designed the technical work, and less so to your team. Instructions for how your team should setup the technical work may therefore not be enough to immediately set the work up correctly.
Finally for hardware, some consultancies give you design and manufacturing files for surface mount PCB electronics. There will always be the risk that there is a mistake in the manufacturing files given.
Managing Risks
(As mentioned before) make sure toolchain setup tutorials are made part of consultancy handover meeting agendas, either remotely on a call or in-person if possible
Give engineers on your team as much time as needed to verify that the design and manufacturing files handed over are correct
Do not blame your team for mistakes leading to delays in this handover period - ensure they are documented properly so that the next handover is smoother
Manufacturing Devices
The saying in hardware that “hardware is hard” is often said when comparing the challenges of the hardware industries to others, particularly software.
The most obvious example of challenge hardware faces that software does not, is manufacturing.
Examples
Changing lead-times and availability of components
Mistakes in the designs that only become apparent after manufacture
Mistakes in manufacturing files
Having an electronics board manufactured and assembled takes weeks, so discovering a mistake after manufacturing has taken place will then require time to debug, rectify then to manufacture again with the same lead time.
The residual impacts of mistakes are particularly challenging with manufacturing, as faulty manufactured devices are sunk costs - there is no choice but to redesign and rebuild.
Managing Risks
Design your system with components with strong availability or at the very least keep backup options in mind for limited availability
Verify your designs as much as possible before manufacturing them (e.g. engineers use “development boards” for verification)
Never rush the process of generating the files needed for manufacturing from the design files. If an engineer on your team wants to spend a few hours going over the components in each file - that is thorough and will save time down the line.
I go more into detail about development boards in Firmware 101 for Startup Founders.
System Integration
If you are building a product that interacts with another (e.g. a wearable device connected to an app), testing features for the first time often takes longer than scheduled.
Adding more parts to the system adds more chances for components to not align as expected.
Examples
Devices that communicate wirelessly, will use their own wireless configurations that are not always aligned with each other on the first test (e.g. wearable device connecting to a smartphone over Bluetooth)
Developers working on separate devices tend not to have domain expertise in the device they are connecting to (e.g. again wearable device connecting to a smartphone over Bluetooth)
Integrating a device physically with one you have not built yourself requires components of specific geometry that is easy to overlook (e.g. a device that is connected to the power system of a car)
Managing Risks
Scheduling as much time as possible for testing and iterating - multiple devices means at least double the edge cases to test, so it’s appropriate to allocate a generous time block here
Encourage in-person or video-call testing if possible to avoid unclear bug reports
For devices you are working with that you did not build yourself, obtain as much documentation as possible, and reach out to the manufacturers directly if you need more info
Regulatory Compliance
Any product being built needs to be legal to sell.
Electronics products need to undergo certification testing based on standards specific to the product and use-cases in order to sell.
The tests can involve going to a test-house and running the device in an enclosed room while a machine measures its emissions.
Large companies will have engineers and teams whose sole focus will be on regulatory compliance, however for smaller teams it is another “hat” for them to learn how to wear.
It is easy for managers and engineers who have not undergone regulatory testing before to see it as a driving test - you turn up with your product, a test-house runs its tests on it and you’re given a certificate or you’re not (on behalf of the notified body).
The reality is notified bodies are used to working with large companies with people who understand their companies standards and therefore expect you to know what your testing criteria is.
Examples
Your device will have to run in modes you are testing for a specific amount of time e.g. if your device goes to sleep after 3 minutes of idle mode, you have to create a test-version that stays on for the hour-long period you are testing for
If you fail tests, you have to retake the tests again when the test-house is available. This can delay product launches and they are also expensive
You may need to verify that data is being sent or received wirelessly by your device while it is in a test chamber - however you have to find the ways to do this, not them. This can require developing an app or software that can record the information
Some tests can either be done in-person or remotely. The remote tests will require detailed work-instructions that you will have to create
Some tests require specific hardware access to the device (for anyone in electronics this is UART). If you have only started working on compliance at the end of your project and realise you do not have access to UART when you need it, you literally have to redesign your device to take this test (!!)
Managing Risks
Make contact with the relevant testing bodies as early as possible during the design phase of your product. Ensure your device has the appropriate inputs and outputs they need and get started on the admin early
Make it clear if you are a startup that you would like support from the test-house
Carry out pre-compliance testing, which involves going to the test-house and carrying out tests to ensure nothing in your design will cause obvious failures. These are paid services however some companies (such as Texas Instruments) offer free services for pre-compliance and compliance support.
Consider bringing in freelance help. Typically test-houses will tell you which standards you should test for, so it is useful to get an impartial opinion to give their opinion
Useful Resources
“The Mythical Man Month” is a book I recommend for people in management and in technology. “Brooks’s Law” came from the book and is widely taught to computer scientists at university. At the very least a glance over some quotes from the book is educational and fun.
Overkill Projects is a great Youtube channel by my former colleague and line manager who told me to read the “Mythical Man Month”. The channel is full of lots of other wisdom too.
“EMC TESTING: THE BEGINNER'S GUIDE” is an online resource for electromagnetic compatibility (EMC) testing, which goes into more detail over the regulatory compliance discussed here.