Process Maps for Agile Startups image

An Insight From the Startup Survival Guide – It’s Never Too Early to Create Your Process Map

There’s more than one way to reach your destination, but you need to draw a map.

Illusional Progress

It’s been a common misunderstanding that startups don’t need too much of processes and organization. You’re just three people spending their own money to write code in the living room and launch an app as soon as possible. You work voluntary overtime and support the whole thing with your bare hands, sometimes literally, because you don’t yet have enough to equip with the necessary tools and infrastructure.

The code is full of quick and dirty solutions around the core genius idea. 

The whole focus is on that core idea – the competitive advantage. It must [seem to] work for the public no matter what efforts it takes behind to keep it alive. Usually, there’s little to no business knowledge in the team, no vision (except the many millions someone will pay them for the app), no actual strategy. You are incapable of onboarding another customer because you don’t have the capacity, nor can you hire another team member. You’re one step from giving the whole thing (your big dream) up. 

If you’re from the lucky ones, you start selling relatively soon. The luckier ones have not reworked, redesigned, reimagined their core feature several times. The most fortunate realize that they need to invest in more diverse know-how when the first sale is signed off. However, it’s a known fact that most startups fail to scale. There’s only one reason for that – wrong focus, lack of vision and waiting for too long before they start laying the foundations of their future. There will be no future if you don’t start organizing for it.

Step Back to Step Further

Remember the so loathed interview question – where do you see yourself in 5 years? (It lost me a job opportunity once – I said that most probably I’m not going to work for that company). That’s a question our Three Musketeers startup must ask themselves every single day. The team must validate every line of code they write, every meeting, every decision against the vision of a company with thousands of customers. There is a straightforward question for this validation – if a production issue happens and there’s a relatively new developer in the team – will they feel confident enough to modify this piece of code and publish the update?

If the answer is not ‘yes’, don’t write that code. Stop, think, spend two days more and make it the right way. ‘We don’t have two days! We’re losing money!’, you are shouting from the hallway, refusing to understand the simple fact that the production issue from the paragraph above will happen not in 5 years but tomorrow after deploying the latest changes. The [only] developer will have to take an emergency day off the next day, they’ll be able to write [another] quick and dirty fix on the day after, but the infrastructure will be down at that time so that the fix will go to production on the 3rd day earliest. 

Does it sound familiar? Congratulations if not, but I doubt it. 

How much can you lose?

Startups lose more than big enterprises. A large company (note that large is not a synonym for mature) can afford bugs – in the code or the organization. The amount of loss will be times higher, but the damage for the company – not so much. It most probably will not destroy the company. We’re witnessing unbelievable production issues from the most prominent manufacturers – cars, phones, social networks. Yet, an enterprise can handle it. But the Three Musketeers can’t. They don’t have any resources to cover failures. 

A startup always needs a backup plan. The backup plan for a startup is the same as for the enterprise – a set of processes, policies and practices to prevent failures and provide quick but clean and safe mechanisms to react if failures still happen. 

Startups focus on short term goals, and that’s understandable. However, they need to focus on the accomplishment that will send them closer to their dream destination, regardless of how far it seems today. 

I’ve recently watched an ad on Instagram of a productivity coach who helps people plan their week. He has this very interesting approach – by Tuesday, do things that will help you make a giant step towards your goals. Prioritize the task to create a more significant difference for your project, company, and life. What happens for most of us is to focus on what we identify as urgent. However, these are never the things that matter most. Smaller or bigger urgencies make us deviate from the right direction. And that’s symptomatic for the startups and their potential failure. 

Are you on the right track?

Startups benefit most from an adequate organization. Just like a toddler, they need continuous guidance in every step. And just like a toddler, it’s not necessary to leave them to learn everything the hard way – it’s just too dangerous. Process architecture is the only way to pave a solid ground for the sustainable growth of a startup.

There is a simple answer to it’s too expensive, and we don’t have time for this now. You have the time, but you have to stop wasting your time, money, and mental powers on activities that progress on the wrong priorities, on things that are not getting you anywhere, rather than delusionally keeping you just above the water.

Now, here’s the big secret – how our tiny Three Musketeers startup can build their process architecture without thinking they spend on something not on their agenda. You can’t imagine how simple it is. The secret to success, sustainable growth, scalability, and business security is keeping a journal and noting daily challenges down. 

I can’t help but mention it – for me, the sole revolutionary Agile principle implemented by Scrum that still tries to change the way people build products is transparency, inspection and adaptation. In terms of processes, this means:

  • Are we aware of the way we work?
  • How do those ways help us get where we want?
  • Are there obstacles on the way?
  • How do we overcome them?
  • Are there other ways that might get us there faster and safer?

Continuously, daily subjecting company life to these questions and noting the answers down, step by step, will build your own set of processes, policies and practices. And I’m not talking about retrospectives – I think they’re useless, to be honest. I’ve observed dozens of teams feeling terrifyingly uncomfortable at retrospectives, no matter what fancy name/pattern we call that gathering. 

What you need is daily awareness – you have daily standups, you raise issues and challenges. Don’t postpone the analysis, do it there on the standup. What to do with these issues? How does the solution become a practice, and what approach will prevent the problem in the future? Is the solution aligned to our long-term goals, and the rookie developer will be able to modify it in 5 years? Open a wiki and start writing that tiny bit of a solution/process down – “in the case of an event A, someone does B, using the input from C, which results in D”. Continue thinking about it, and that formula will transform into “to prevent risk A, someone does B, using the input from C”. 

Start Drawing

As you see, it gets simplified over time because the more you think process-wise, the more crystal-clear it becomes to the whole team that everything is a process and subject to refinement. The simpler it gets, the lower the management cost, the lower the risk, the quicker the execution, the faster the results, the more certain the growth. 

Naturally, writing instructions like this needs visualization, so find a drawing tool and draw the flowchart of the steps. Then link it to the related, interfaced flowchart for another type of events. Flowchart by flowchart, you’ll build your map of flowcharts, or as I like to call it fancier – a process architecture that will enable your tiny startup to dream big, grow fearlessly and befriend more and bigger customers. 

If you’re willing to put this strategy into action right away and get a personal review of your current organization? Book an appointment, and let’s find out the best approach for your context together.