Week 1. A new technology startup is born. A hands on, tech savvy, entrepreneur found a purposeful project to work on. He brings the best people he can. Sooner than expected a team composed of sales, marketing, product and technology people assembles. Ideas start flowing. Drawings on the wall, napkins, desks and coffee stained notepads let you know that something is brewing.
Week 13. The main course of action has been established. The startup is moving to build/test/iterate phase. Product managers are eager to see the results of their initiatives which will make the company reach the next level. Software engineers are excited and will work overtime to hit the deadline, while maintaining a highly sophisticated distributed architecture with easy to use CD/CI pipeline.
The grand picture was described as a full blown AI, VR, Blockchain, Machine Learning, Big Data powered platform with loveable and superior user experience which captivates happy paying customers. But…. reality is that, in startups there are only so many hands, so much time, and so much money to fuel the time of those hands.
After negotiating with a poker face engineering manager, many features are shed, still the scope is huge. Hesitantly, the team agrees to the scope. but they let all stakeholders know that given the time and resources they will build many features using a scaffolding approach. Engineers made sure to inform everyone that even though the delivered product “works fine” for the initial use case, it is not a final solution. It is more like a proof of concept.
Week 33. Good news! The product is out. Your whiz marketing person makes the best out of a shoestring budget and manages to get a significant amount of users to your site. One of the features seems to be on track to prove your business idea. Less than a week after the initial release, there is a list of features that will potentiate the winner feature and improve the so so ones.
After reviewing the list, the software engineers realize that what on the surface look like small changes, compromise the “scaffolding solution”. Time is running out but there is hope. If the team can only add these set of features, even if they are temporary solutions it will prove the value of the product.
Week 53. The company is thriving but, even with twice the amount of engineers, each new feature is taking longer and longer. The scaffolding never ended. Instead of having a world class platform, the company has a profitable product that needs to scale but crumbles on each release. Product and sales teams blame engineering for delays. Engineers blame product and sales for not being thorough when defining a product and for not giving time to think and build the beautiful and elegant piece of technology that they would have bragged about in software conferences.
Week 72. Technical and managerial debt is too damn high! Everyone is stressed out and working together is hard. Not because everyone dislikes each other but because everyone knows there are better ways to work. Morale is slowly declining. Business must carry on.
Does this sound familiar? This is the story of many startups, of many teams, of many smart and hardworking people. Good news is that regardless of the product, the technology or the industry you can write a different story by improving the culture in your startup. I learned mostly the hard way, but you don’t have to. Here are some of my recommendations:
- Enforce good practices from the very beginning. Clear definition of requirements, code linters, code review sessions, architectural assessment, neat use of code versioning, style guides, data structure standards, reporting conventions, etc. might sound too much for a young and small startup. It is not! Each bad practice that lives in your ecosystem is like cancer. You might get lucky and get rid of it along the way but when it is widely spread it is deadly.
- Stand on the shoulders of giants. Unless you are working on the bleeding edge of technology, most of the problems you will find have been solved by someone else. If you do your research you will find that those who solved your problem wrote a paper, recorded a conference or wrote a book about it. Even further, in some instances there might be a free or pay as you go service that is exactly what you need.
- Reach out to your peers in other companies. I’m always amazed of how open people are to talk about their problems and how they are tackling them. Reach out to your network, ask for introductions when you know someone who knows someone.
- Value craftsmanship. Good definitions take time, good estimations take experience, awesome products take both. Getting things done matters but doing things the right way matters more. Try hard to identify craftsmanship in your teams. Learn to recognize the quality gains of giving a bit more time, a better tool, a clearer definition. Identify and respect rituals that make someone else’s job better. They might become your main source of information when formalizing processes.
- Plan for technical and managerial debt. It sounds horrible. Am I recommending to rewrite a business process manual? To refactor code that should’ve been done right the first time around? YES! Organizations are living entities that change over time, startups change really fast in early stages. Even for great teams foreseeing all potential changes is difficult. You don’t build your house everyday but you do clean it everyday. Every debt has a compound effect, the longer you take to pay for it the more difficult it will be later.
- Invest in tools to support your product. If you are launching a great product that generates revenue and customers love. That is great! But if in all instances it needs to be operated by software engineers, you are in for a big resourcing issue. While building your product try to have in mind: What tools are going to support it? How would you add a new configuration? How are system administrators going to access important information? How can you turn off a given feature? Some of these might sound obvious but while you are sprinting towards delivering a feature you might not give any attention to it. Even worst, you might decide not to invest at least in a plan to support it in the near feature.
- Make yourself and others life easier. Have you ever found yourself doing boring repetitive tasks. Have you found a way to automate it? To shed 20 minutes from your workday? Share it with others, if you save 20 mins/day/people. You are saving about 100 working days to the company while enabling your peers to focus on more complex issues.
- Encourage negotiation. I cannot tell you how many times I have asked an engineer why a given task or feature is taking longer than expected. The answer might go something like “This dataset must be transformed to a format B per John‘s request.”. Then I find out that data exists in format A which seems to be reflect the same information as format B. Then, two days of work become this 5 seconds of conversation. “Hey John, we already have data in format A and it contains the same information than format B. Can we deliver in format A?” to which John replies: “Yes. I didn’t know format A even existed that is why I requested format B.”.
As you might have noticed, my suggestions are mostly for product and technology teams, which for technology startups are usually the larger portion of the organization. The best day to start is the very first day, the second best day is today.
Please share your thoughts in the comments section? Are there other good practices you would recommend?
For more articles please visit www.nascento.com