On development - How to design an effective intake process
Wrangle the chaos of startup life through the implementation of lightweight, efficient processes.
Wrangle the chaos of startup life through the implementation of lightweight, efficient processes.
Process is an afterthought for many tech startups and an intake process is often the last thing on leadership’s minds.
After all, they haven’t needed it so far. In the day-to-day chaos, things have happened and progress was made just fine without any formal process.
They may even have started thinking that an intake process isn’t even necessary and would just slow things down. Perhaps they’ve come to believe that their team has somehow found some special trick to make such process completely unnecessary.
They deceive themselves. It’s understandable how inexperienced engineering leads get lulled into this dangerously false sense of security. The lack of structure that was once the competitive edge of a small team of 10 quickly becomes the achilles heel for a larger company of 50 or 350.
Growth changes the game
As startups grow, the complexity of the projects grows and the inter-team collaboration demands increase exponentially.
Focuses shift. Tasks get re-prioritized. Projects get cancelled and renewed. Change is constant. Many requests inevitably slip between the cracks and get lost.
From the outside, the development team becomes a black hole — nobody in the organization quite knows what the developers are working on, and it’s already hard enough to understand just exactly what a developer does without this.
External teams without insight into the day-to-day of development begin to lose awareness of the status of requests they made — requests that they desperately need completed to move the needle on the company’s objectives. They waste time pinging individual engineers, or make false assumptions that cause their own initiatives to abruptly come to a screeching halt.
The means by which a request actually gets done ends up becoming opaque. Whether a request gets fulfilled or not gets done becomes determined by the whims of the person being asked, informed by the relationship between the asker and the askee. It becomes a barter economy where important things get dropped while less important things get done just because someone was friends with an engineer or they exchanged favors. This doesn’t make for an effective prioritization culture — it is a pathological, political one.
Cultures like this sow the seeds of doubt about the development team’s effectiveness and, over the long-term, turns into mistrust of the development organization as whole—a perception all engineering leaders should strive to change.
Effects of a good intake process
If intake processes become necessary after growth, how does it actually help?
It helps individual developers be more effective.
It allows for effective planning across the entire organization.
It provides signals that can be acted upon.
It helps ensure prioritization is explicit and obvious.
It helps individual developers be more effective.
At some point in their career, every software developer will have someone in another department asks them for a favor. The initial request is often small — perhaps it a “really quick” text change, or a small fix for a bug that’s been bothering them for a long time. The ask might be made in a passing comment in the hallway or via a short email:
The developer does it, because “Why not?” —it’s only going to take 10 minutes. The next day, they get another request, which they dutifully do. Then, another….and another…. and another. Soon, others are also making requests because they heard that’s how things get done. The developer doesn’t say no. They just start working late or slow down on their other tasks. Ah, the curse of being reliable.
This is the invisible hand of hidden work. It drags on teams causing immeasurable amounts of inefficiency and distraction. the hidden work is impossible to accurately plan for because it happens in the shadows of people’s individual inboxes and water-cooler conversations.
Having an effective intake process shines a spotlight on hidden work. It doesn’t mean that this hidden work never gets done or is never prioritized — it just means that everyone is aware of it, not just the people in the conversation.
High visibility lets you account for all of the hidden work in your planning, ensuring resourcing, prioritization, and scheduling are appropriate.
It allows for effective planning across the entire organization.
For external teams operating in an environment without an intake process, making a request may feel like “tossing something into a black hole”. When will it be done? Who knows. Will it get done? Roll a dice. Will you be told when anything happens on it? Probably not.
Operating in a zero-information environment like that can only lead to tragedy. For example, Sales may commit something with a key customer believing a request they submitted weeks ago had been completed, when in reality it may not even have been started! When they find out a week before it is due that it hasn’t even been looked at yet, it causes a fire in engineering to rush and get it out, or an unhappy key account.
Incidents like this build frustration in the organization and ultimately hurts cross-functional collaboration.
An effective intake process importantly makes status and progress visible to the requestor, providing clarity and improving cross-departmental collaboration and trust.
This clarity promotes better synchronization as dependable intake cycles can be planned with in mind, especially important when collaborating with departments that have longer cycles, such as Marketing and Sales for go-to-market initiatives.
It provides signals that can be acted upon.
Finally, an intake process helps maximize the long-term effectiveness of the development team by providing opportunities to collect trailing and leading indicators of how the team is doing.
It provides you an opportunity to get insight and take action based on the kinds of requests you are getting, or how long things are taking.
Suddenly getting an influx of bug requests? You may have a quality issue.
Getting an influx of data asks? Perhaps it’s time to expand the data science team.
Cycle time suddenly skyrocked? Perhaps requirements are not defined well-enough.
Whatever the case, you can’t get these signals unless you’re looking for them.
It helps ensure prioritization is explicit and obvious
Without an effective intake process, prioritization is often dictated by the person with the most acronyms in their title or the squeakiest wheel.
or smaller, less influential members of your startup, it’s hard to get prioritization and they may feel like nobody has their back. This is a problem that customer success and operations teams often have, despite being the front-line for user contact and the first-impression of your company many people get.
I’ve seen situations where companies were spending tens of thousands of dollars in salaries to solve something that could have been permanently resolved with just 10 minutes of developer time. Savings like this would never have been prioritized or even remembered to be addressed had they not been explicitly tracked.
How do you implement an intake process?
Implementing a new intake process is just about the same as implementing any process change in a company:
Keep reading with a 7-day free trial
Subscribe to Joseph Gefroh to keep reading this post and get 7 days of free access to the full post archives.