Promoting innovation
The Zinnia Hybrid Origination Engineering Blog is a tool for connecting with the technical community. We discuss engineering challenges, approaches, and give you the inside scoop on what makes our team tick and how we keep things fun and efficient.
It is essential that tech companies dedicate a portion of engineering work to innovation. If you are part of an early startup, you hopefully work in a team building a new innovative product with fresh new ideas and a brand new market fit; a lot of the work you do is related to innovation. As the company and product mature, parts of the product might become outdated, or unable to scale. Code gets stale and work becomes redundant and less exciting.
That’s exactly when keeping innovation going is most important. Actively working towards innovation can positively impact the company on multiple levels. On the business side, it can enable us to stay ahead of the competition, attract new clients, and encourage the growth of the company. From an engineering standpoint, it helps reduce technical debt while keeping the team motivated as members learn new skills. From a product perspective, it improves feature flexibility and velocity.
There are numerous methods for fostering innovation, and the ideal approach will vary depending on the organization’s work and team structure. It is however crucial that innovation originates from the bottom up, and that leaders facilitate these opportunities.. To illustrate, let’s examine some of the initiatives implemented by our team to promote creativity and forward thinking.
Hackathons
Introducing hackathons in the workplace can be a great way to stimulate creativity and foster innovative thinking. Hackathons provide an opportunity to develop prototypes for new features and find solutions to existing problems. They can also be used to promote collaboration and knowledge sharing across teams that do not otherwise work together on a daily basis.
Here is how we organize hackathons.
Step 1: Gathering ideas
The most important aspect of a hackathon is to enable a bottom-up flow of ideas by inviting all employees to submit projects. The only requirement is for these to bring some kind of business value. To ensure that the ideas are actionable within the hackathon timeframe, all project suggestions must be submitted through a form containing a project description and an estimated required team size. This information is crucial to help us form effective teams.
Step 2: Selecting projects
We select projects democratically: all participants vote to indicate their first, second, and third preferred projects using a custom form. We then exclude projects that receive insufficient votes to keep the number of projects contingent on the number of people joining the hackathon.
Step 3: Putting the teams together
This step is usually the hardest! We factor in the total number of people involved in the hackathon, the number of people needed per idea, and participant preferences to form appropriate team composition. While we strive to place as many people as possible in their first choice of project, we may have to assign some to their second or third choice. The originator of the idea is designated as the leader of that project’s team and relied upon for directions. We also aim to combine members from different teams together. We realized that colleagues from the same team will often vote for the same hackathon project because it aligns with their domain of expertise. However, mixing people from different teams encourages different perspectives, fosters company-wide team-building, and maximizes the benefits of the event
Step 4: Building it
During the duration of the hackathon, it’s important to limit distractions as much as possible. Some teams are more susceptible to external disruptions, like platform monitoring and client support. It’s essential to put a plan in place prior to starting the event to manage these distractions so that all team members have an equal opportunity to participate. It’s also important for managers to be notified in advance should any members be unavailable or have limited availability for the hackathon.
Step 5: Wrapping it up
At the end of the hackathon, a company-wide presentation is organized. Teams are given the opportunity to showcase their projects, share their discoveries, and demonstrate the potential business value of their findings.
This presentation is the culmination of the hackathon, so it’s important to make it as interesting as possible. We have found that awarding non-negligible prizes to the members of the team with the best presentation is a great way to retain interest without inflicting undue pressure. It also provides a convivial atmosphere for employees to work on their communication and presentation skills. Ultimately, even if a team cannot present a finished project, they can still be rewarded for their valuable insights and great presentation. Feel free to be creative with prizes! You may include a custom trophy that the winners can brag about, gift cards, or even a giant rubber duck to help with spicy debugging sessions.
Step 6: Following up on the projects
Upon completion of the hackathon, our leadership is responsible for reviewing the projects, evaluating their current state, and deciding on the next steps. We do not expect project completion at the end of a hackathon. Instead, we evaluate the project direction, business value, and remaining work to create a finished product. Based on these factors, we decide which projects to discontinue, which ones to put on the roadmap, and which ones to re-evaluate later. It is also important to keep in mind that a hackathon is meant to promote innovation while allowing the team to relax, deepen relationships, and have a good time.
The duration and frequency of the hackathon can vary based on the needs of the company. We have found that holding a two-day hackathon twice a year is a good formula for us. It is short enough to not interfere with team planning and roadmap, yet long enough for teams to realize an effective proof of concept. We strongly advise that the hackathon takes place only during working hours in order to maintain a good work-life balance. We do not encourage our people to burn out on an energy drink-fueled spree just to see who can achieve the most in 48 hours!
Organizations with larger teams may benefit from organizing department-wide hackathons instead of company-wide hackathons. This approach may make it simpler to plan and may yield greater engagement among participants who will appreciate focusing on topics that relate to their regular responsibilities.
Carved-out time for engineering work
When working on a team roadmap, it is easy to let product features and client demands take up the majority of the time, leaving little to no room for engineering work. Innovation rarely “just happens”. To make sure it does, carve out space for it by setting aside a portion of team velocity specifically for engineering initiatives. These include addressing technical debt, codebase refactoring, research, working on a proof of concept, or learning new tools and languages. We found reserving 20% of our teams’ time for these types of projects to be a perfect balance; it introduces some flexibility without having too great of an impact on other initiatives. All team managers need to be on board and enforce that 20% of velocity be allocated to engineering.
Teams are free to adapt their approach to engineering work to their context and skillset. Some include their 20% in every sprint, while others opt for a “cool-down sprint” entirely dedicated to engineering work every five sprints. Even though this chunk of time is not reserved exclusively for innovation, initiatives undertaken during the 20% often lead to innovation because they originate from the engineers’ deep knowledge of the product’s limitations and areas of improvement on the platform. While these initiatives can be initiated directly by the teams, they still have to be approved by team leaders, prioritized, and placed into the team roadmap. This way, we can better keep track of how much business value each initiative provides and how much effort is put into it.
ADR
Architecture Decision Records (ADRs) are another effective tool for promoting innovation because they help with recording, documenting, and communicating decisions made throughout the innovation process. As a company grows, documenting architecture decisions becomes critical to ensure that product development is aligned with the company vision, and that all stakeholders are aware of significant decisions. Keeping documentation of past decisions will be useful in the future when we question why a certain direction was taken and what problem was being addressed.
In addition to promoting innovation, ADRs help frame and execute innovation projects. As problem solvers, engineers can tend to dive into one solution without considering all aspects of a problem. ADRs incentivize teams to better understand the issue they are tackling before jumping into solutions, and compel them to outline various approaches before settling on one.
It is imperative that ADR creation be driven from the bottom up, with engineers taking the lead. They are the ones on the frontline and they have the most context about the product limitations and areas of friction. By having the engineers driving the ADRs, the team can more accurately identify the platform’s main areas of concern and come to a consensus about the desired solution and implementation.
An ADR document is composed of three sections that correspond to three phases of decision-making: Discovery, Decision, and Preparation.
- Discovery: In this section, we explore the context and problem statement. We identify high-level solutions and engage stakeholders in a discussion on which all team members have visibility
- Decision: In the second section, we evaluate different approaches. We discuss the pros and cons and describe the proofs-of-concept that we may have built in order to arrive at a consensus.
- Preparation: In this final section, we aggregate all information related to the decision process, define functional and non-functional requirements, and estimate the efforts required to complete the initiative.
You can find more information about ADRs here: https://adr.github.io/ and here: https://github.com/joelparkerhenderson/architecture-decision-record. This is a useful template to use as a starting point for your own ADR template: https://github.com/joelparkerhenderson/architecture-decision-record/blob/main/templates/decision-record-template-madr/index.md
Conclusion
By having regular hackathons, reserving a percentage of a team’s velocity for innovation, and implementing architecture decision records, companies can create an environment that encourages innovation and creativity, thereby keeping them ahead of the competition and ensuring their continued success!
