Tag: kanban

The minimalistic Start-Up – Structure of the team

These days, many articles explain how people must have a side hustle and create multiple income sources. Unfortunately, one significant disadvantage of this media is that it does not successfully demonstrate how to build such a side hustle. It does not list the disadvantages and sacrifices coming with having such. And finally, it does not explain how to create a team working on that side hustle. This part will address these challenges and describe how our hypothetical team can resolve them.

But let’s start with listing the main disadvantages of having a side hustle:

  • Time-consuming – If the team wants to have a successful spell working on the hustle, each member must allocate a minimum of ten hours per week. Suppose you try combining it with having a family. In that case, things could become quite hairy because people start balancing between their family and their side hustle, which often leads to disaster.
  • Distraction – Having a side hustle could affect people’s primary income source because they spend the dedicated weekly amount of time working instead of resting. Such a way of work requires motivation and internal drive in the long term.
  • Could be expensive – By default, the main expenditure for every Start-Up is its marketing. And to generate an income, every company needs marketing. It does not matter whether it is a fully-fledged organization or just a side hustle. Without marketing, there is no money coming. And yeah, marketing could be costly.
  • Not perceived as serious – One of the main problems with side hustles is that customers do not perceive them as a serious endeavor. And unfortunately, such prejudice is often correct – nowadays, customers expect organizations to have excellent support in addition to the products and services offered. Dedicating around ten hours per week for the side hustle is usually not enough to cover all the product development aspects and product support. 
You can see a standard dropshipping side hustle on the diagram, where the team “just creates” a website and starts earning money. The main problem is step one – how do you ensure that the routed “traffic” will start buying your products

After listing all the most critical disadvantages, let’s see how our hypothetical team can overcome them. The mandatory requirement for a moderately successful side hustle is to have at least ten hours per team member per week. In real life, if one of the team members can not dedicate such an amount of time per week, the setup becomes fragile, and there is a high chance of disaster. Having this prerequisite fulfilled, our fictional group could use the following mechanisms to improve their efficiency:

  • Meetings every two weeks – The standard agile workflow dictates having synchronization meetings at least twice per week. However, in our situation, the amount of time dedicated per week is four times less, which logically dictates that having four times fewer meetings will keep the team in good shape and, at the same time, will keep the work tempo high.
  • Have a single decision-maker – With teams of less than seven people (the maximum number of people participating in a side hustle), the most efficient team structure is flat. Such form speeds up dramatically the decision-making process and makes sure that the team is not stuck in endless discussions and arguments.
  • Make the expectations clear – With so few hours per week, there is no space for flexibility. From the beginning to the end, the team must know their priorities and what they could expect from this side hustle. Any change in these priorities will lead to a lack of focus and decreased level of motivation.
  • Have fun – Too many people take too seriously their side hustles. They genuinely believe that they could scale their hustle to a multi-billion company with many employees and branch offices. Unfortunately, in reality, the main advantage of doing a side hustle is learning new skills and investing your time in something meaningful. Earning money for 99% of these endeavors is a chimera, especially if the team members do not have the proper background and experience in starting up new products or companies.

We shall have three back-end devs, one front-end/designer, and one dev-ops member in our hypothetical team. They will dedicate ten hours per week to the project, and one of the back-ends will be the squad leader. Every two weeks, they will have a two-hour call to discuss the current status and decide what they will do next. Additionally, they will use Slack, Github, and GSuite for synchronization.

In conclusion, I would emphasize taking the upper statements with a grain of salt. They helped me in my previous experiences. I have used side hustles from an early age to keep myself in shape and learn new skills. For example, I took my bachelor’s and master’s degrees and worked full time simultaneously. However, such dynamics will take their toll on most people quickly and could even lead to burnout or diseases. Given that, I would advise you to choose your teammates carefully – not everyone is “crazy” enough to live such a lifestyle.

Agile for Start-Ups – part 2

In the last article, I shared the usual disadvantages when teams use agile methods in early Start-Ups. In this part, I shall give you my list of modifications and changes over the standard agile workflows. All of them are based on my experience and errors accumulated during the years working in underfunded Start-Ups. Additionally, I shall give you additional information regarding how it can affect team morale and motivation for every modification. But let me list the different changes I used during the years:

  • Do not do peer reviews: Peer reviews work pretty well for improving code quality and knowledge sharing. However, they are one of the biggest bottlenecks in your team workflow. Additionally, to have productive peer reviews, the peers must usually be at the same level of expertise. The best case is for the reviewers to be with more considerable expertise than the reviewed. For early-stage Start-Ups, I would suggest senior management appoint two or three people to do all the code reviews in the company. With this approach, team morale and motivation will increase because you would avoid much friction and drama.
  • Avoid unit tests: Unit tests are one of the best ways to increase your code quality. However, during the early stages of your product, where you do a lot of research and expect significant refactoring of the code base, unit tests, constant maintenance can kill your velocity and hurt your team morale. Usually, after the initial effort to create the tests, the team stops maintaining them after a couple of tight deadlines, and finally, they are entirely disabled. Better spend your time doing integration, smoke, or component tests because they work on established APIs, and these APIs do not change dramatically.
On the diagram, you can see the traditional technical team structure of four layers. In early-stage Start-Ups the positions CTO, Head of Development, and Team Lead are usually held by the same person
  • Don’t be sloppy with your architecture: Make sure your technical architecture is solid and can be upgraded or refactored easily. Quality of code is not so important because you can improve your code quality quickly, but not your architecture. Many teams decide to start with less complex architecture, and after that, they have to reimplement the solution. Better, plan how you are going to implement your architecture in phases with change in mind. Start with only the essential components and upgrade them later. Doing something twice is the most significant morale and motivation killer in one team.
  • Do not estimate R&D: Early-stage Start-Ups usually must not plan research and development. It would be best to entirely avoid research and development and work on already established business or technical models with minor modifications. Innovation is expensive in terms of time and money. It should be avoided or minimized as much as possible.
  • Threat every task as a different sub-project: Many company owners love to categorize their products using the famous triangle of quality, speed, and time. However, the major mistake is that a software product is a collection of submodules. And every submodule comes with its complexity and implementation. It is much better to treat every submodule as a separate project and decide what we expect using the quality, speed, and time triangle.

In conclusion, these are my leading suggestions for every early-stage Start-Up team. To extend your Start-Up life, you should cut time and resources from every non-essential part. My proposed list gives some hints in that direction, and I am sure you could create your lists by filtering what the essential and not the essential activities in your team are.

Agile for Start-Ups – part 1

I want to start these two articles by observing that I don’t believe agile methods are appropriate in their proper form for Start-Ups. In the first article, I will list most of the disadvantages of the agile methodologies and how they could hurt the Start-Up’s performance. In the second one, I shall present what worked for me in the past and what did not. 

But let’s start with little history of the product management frameworks and how they evolved. Historically the initial management framework was the so-named waterfall or phased approach. With that approach, the companies copied how most engineering products are created by multiple phases and initial requirements gathering. This way of working does an excellent job when you want your solution to be installed on-premise and must work for a long time without interruption. 

In the 80s of the last century, Watts Humphrey, during his work at Carnegie Mellon University, founded the Software Process Program, and with that, he started the so-named PSP (Personal Software Process). This process heavily relies on not comparing the performance between different developers but rather trying to improve every developer as a single unit. Additionally, in PSP, we have the notation of knowledge re-usage – aka if the developer has implemented something similar as a block in the past, we could expect him to implement such block with the same speed.

In 1986 Hirotaka Takeuchi and Ikujiro Nonaka started Scrum and the foundation of different agile methodologies. At its core, the agile development process defines that the “customer/client/company owner” will work together with the team and provide business knowledge and requirements weekly. A fundamental principle of Scrum is the dual recognition that customers will change the scope of what is wanted (often called requirements volatility) and that there will be unpredictable challenges — for which a predictive or planned approach is not suited. These changes come from various sources, but understanding why is irrelevant: change should be accepted, embraced, and analyzed for benefits.

On the diagram, you can see the standard agile workflow. Its typical duration is between 1 and 4 weeks. In Start-Ups, the main problem is during the planning meeting because it is impossible to plan R&D

And now here are some reasons they do not work well for complex Start-Ups:

  • R&D: All of the listed methods work on the assumption that the team will not do any research and development. Aka, the business owners know their business niche and that someone else already did the R&D part. In reality, this rarely happens, except when we start a business without any innovation. When you want to make an innovation, all traditional product management frameworks stop working. Usually, in the Start-Up World, the team must do R&D and code writing simultaneously (investors and clients want to see progress).
  • Burnouts: Constant changes in business requirements and business situations usually involve many changes in the technology stack and your programming code. Sometimes you must rewrite the whole product from zero. And this typically takes its toll on the engineering team. For sure, if you do not manage to make business traction (aka finding clients) for the first three years of your Start-Up, it is virtually certain that this lack of progress will demotivate your technical team, and most probably some of the members will feel the effects of burnout.
  • The process will not mitigate your people’s weaknesses: According to most agile methodologies fans, these methods are the panacea for every technological problem. However, we have to ask ourselves why only 5% of the Start-Up technical companies pass the second year of work? All of them use these methodologies. For sure, we could blame the business development and marketing, and we will be right that 70-80% of one successful business is the way you sell. However, at the same time, I saw many technical teams struggling in their performance because of leaning too much on the agile principles.

In conclusion, I would want to emphasize that no product management workflow in the World will mitigate the weaknesses your team has in the first three years of your Start-Up. The only way to increase your team productivity is by training them, and by training, I mean the business and the psychological part of being into a Start-Up. Technical knowledge is much easier to adopt and realize than handling that your odds of winning a VC are 1:300.