We have all worked at lots of software companies in our careers. We all report the same problems &ndash; issues with culture, process, and systems slowing down the planning, building, and running of great software. We started Atono to change the accepted status quo.

To help teams communicate, work together, and build better software.&nbsp;

Our big, hairy, and very audacious goal is to become the most widely used platform to plan, build, run, and improve software.
It&rsquo;s ok to snicker. We know what we&rsquo;re up against.
We also know that people build better software together. Not in a linear assembly line, not across eight applications, not in broken cultures with highly customized versions of on-premises Jira. We&rsquo;re setting out to build a platform for teams that want to work better together.&nbsp;

Today, we are a team of 19 people - 10 women and 9 men. We&rsquo;re 90+% Canadian, 10% American, which is 100% North American, so we&rsquo;re all really &ldquo;American&rdquo; (my Canadian colleagues won&rsquo;t read the website, so I can get away with that comment). We closed a $4M seed round in March 2024, let&rsquo;s go!

We have several strategic principles that direct our actions and help us make good decisions:
<ol>
<li>We're developing our organization in the open. We are sharing what we know with anyone who needs it.</li>
<li>We're building a customer-first organization. We believe you should be able to buy the product the way you want, self-service, &agrave; la carte, with sustainable but low prices and a money-back satisfaction guarantee.</li>
<li>We'll spend hours to save you a minute. We're obsessed with saving you time.</li>
<li>We can make more money, but we can&rsquo;t make more time. The same goes for you, so we hate waste.&nbsp;Find it, root it out. We're building our software to help you root out friction.</li>
</ol>

We have 17 principles or values that address how we act, how we treat others, and how we make decisions. 17 is 14 too many, but we&rsquo;re still young and experimenting. The underlying theme is humility, and if we had to pick three, they would be:
<ul>
<li>Be curious: Embrace experimentation and failure so we can learn and grow</li>
<li>Be a team: We win and lose together (serving one another as we go)</li>
<li>Be real: Every internal and external interaction is consistent with our principles</li>
</ul>
Click <a href="/handbook/what-we-believe/">here</a> to read all 17.&nbsp;

We are lucky to work together again.
We all worked with one another at different times at a previous company. This was important in building the founding team not for sameness or like-mindedness but for a common language of culture. Trust me, we argue, but in a good-spirited way, we employ the &ldquo;best idea wins&rdquo; of problem-solving, and we all get behind the chosen initial direction.
We also don&rsquo;t take things too seriously. We're serious about building excellent software, ensuring the system is up, performant, snappy, and fun to use. We're serious about supporting one another. But besides that, we try not to take things too seriously.
We enjoy a good laugh and Friday Beers (or Diet Pepsi). We also understand that we have started a marathon of sprints, so personal time is important. We honor that.
We have also all worked in places that we didn&rsquo;t love. So, we're excited and grateful for this opportunity to make an amazing product for the software community everywhere. Each of our baker&rsquo;s dozen are founders.

We are working remotely today. Its good and bad. To make sure we're building relationships we have several tools:
<ul>
<li>Daily standups. We run a daily standup for 15 or so minutes. The hot potato is passed and any updates are shared. The typical format: what I did yesterday, what I will focus on today, where I am blocked. Team members volunteer to help with blockers, and if we have extra time, we size stories. Monthly all-hands meetings are not really needed because daily updates are shared. When we get big and stodgy, we'll bring back the beloved AHM.</li>
<li>Hometown meetups. Every other month, we get together in our local geography for a day (1/2 in Victoria, BC, and 1/2 in Vancouver, BC). We spend 1/2 of the day on shared topics and 1/2 of the day working in the same space.</li>
<li>Full team meetups. Every other month (the other month from the above month), the entire team gets together in either Victoria or Vancouver on a rotating basis. We generally spend 1/2 the day on shared topics and 1/2 of the day doing something else, like watching Dune 2.</li>
<li>1-1's. One-on-ones are held weekly for 30 minutes. Similar format to the standups - what's going well, what's not, and where are you blocked? We exercise candor to make sure we are improving.</li>
</ul>

When you experience how great it is to work on a team that gets things done &ndash; well and on time &ndash; you want to do it again. That often isn't the case for most people, but it really should be. At Atono, we want to make that the norm.
We started discussing our concepts ten years before founding Atono. We were frustrated with the status quo, so we built new ways of working in software development. We had teams built around the job to be done, not reporting lines. Leaders were promoted based on their ability to lead, not their functional background. We built feature flagging so developers could flip their own flags. We delivered on time every time. The culture was pretty blameless. Our people were happy, our service was resilient, and our customers received real value. Then we got acquired - and things changed.
As we were reminiscing about the good old days, we began to wonder: what if we built a company that learned from all the mistakes of the previous one? What if we focused on a big problem that affects every software development team? What if we re-envisioned the software development cycle and built an application to facilitate that? How would AI come into the picture?
All those thoughts lead to Atono.&nbsp;
So where are we now? Let&rsquo;s rewind a few months.

We kick off Atono (then known as SameTeam). We recruited our founding members to start on December 1st and then promptly asked them to take the first month off as vacation. We wanted everyone to be well rested, have time to research areas of interest, and have a fresh start. &nbsp;

We met in Victoria, BC to build our roadmap, design our initial culture, and start to define our first take at MVP. Each developer presents some research findings and recommendations. We made quick decisions and started the CRUD work which also included banks, incorporation, initial financing, payroll, etc. &nbsp;We all knew Jira, so we picked Click-up to run development.&nbsp;

We defined MVP, took a SWAG (Scientific Wild Ass Guess) at the size of the work, and picked December 2024. We don&rsquo;t know the size of the epics, stories, tasks, or the velocity of our work - so yes, December sounds like a winner. Our definition of MVP is &ldquo;atono can run our software development processes using our own product.&rdquo; It will have some rough edges, but any team should be able to plan and build software using this first version. We also changed the name from SameTeam to Atono. &nbsp;Atono means unstressed, exactly how our customers should feel. &nbsp;We expanded our team to 10, co-founder Tobias worked from Mexico and we narrowed down our VC prospect list from 250 to 75. It was a busy month.

The product is starting to come together. Users, Teams, Roles &amp; Permissions are beginning to take shape. Some nice touches like drag-and-drop are getting built. We are running about one week behind our pace for MVP, but our velocity is increasing. Our ceremonies (standup, planning, design reviews, retro&rsquo;s) are working like a well-oiled machine. We need a website so that work has kicked off. We switched from Click-up to Linear. &nbsp;We have lots to say about both apps. Oh, and we saw Dune 2 all together - loved every second.

I&rsquo;ve been lost at sea for two years now and a volleyball is my best friend. Alright, it&rsquo;s not that bad, but working remotely is hard. We met in both Victoria and Vancouver for our meetups. Our development velocity continues to improve. &nbsp;We&rsquo;ve started building parallel product tracks (two epics at the same time) because we were crowding stories and creating bottlenecks. We&rsquo;re working on our new Slack capabilities this month, it&rsquo;s cool. Tobias went to Japan, visited a Capybara, and now we have a mascot.&nbsp;

Well, we knew pivots would be needed. As we built, we realized our brand required refactoring. If at first, you don&rsquo;t succeed, iter8! We love the new system. We also produced lots of content for our handbook, soon to be public. We selected Readme and Contentful for docs and our CMS respectfully. We are knee-deep in feature flags (flipping on and off from within the story) and the new Slack capabilities. Velocity is holding steady, hoping to improve a bit in the summer.&nbsp;

June brought good weather, finally! We also produced the first website which we're developing in public. So, don't mind the imperfections here and there. We also built a storytelling demo version of Atono to show the goodness in practice. We continued wrapping up Slack, working on feature flags, and added work on the &ldquo;bugs&rdquo; module. Is a bug different from a story? We think so and that bugs can be managed more efficiently. The proof is in the pudding.&nbsp;

In the next six months, we are building the rest of the product and our business infrastructure. We are experimenting with a buyer-led journey&mdash;it is exactly how it sounds&mdash;the buyer buys the way they want. That may include a la carte pricing, everyday low prices, self-service, and a money-back satisfaction guarantee, to name a few ideas we&rsquo;re working on. We also need to build a fully operational website, develop a presence in development communities, attend development events, run user interviews, and much more.
We have lots to do, but we&rsquo;re enjoying the journey.

When we started Atono, we knew culture was going to be really important. It&rsquo;s perhaps our most valuable asset because it supports our people.

A culture is a way of life for a group of people - the behaviors, beliefs, values, and symbols they accept - without thinking about them and passed along by communication and imitation from one generation to the next.
We decided on our values from day one to accelerate decision-making. While we can always thoughtfully revise these founding principles as we gain more experience, their main purpose is to build our culture and empower every person to make quicker, better decisions.&nbsp;

We created this list even before the team started working together. It's now shown to every new member who joins the company, and we periodically review them to make sure they reflect our historic actions and future perspective.
<h6>How we act</h6>
<ul>
<li>Be curious: Embrace experimentation and failure to learn and grow&nbsp;</li>
<li>Be humble: Check your ego at the door</li>
<li>Be brave: Disrupt the status quo, including our own</li>
<li>Own it: Honor our autonomy by also accepting responsibility</li>
<li>Ship it: Ship a beautiful product on time</li>
<li>Compete: Respect the competition, but compete to best serve the customer</li>
</ul>
<h6>How we treat others</h6>
<ul>
<li>Same team: Win and lose together, so serve others, ask for help, and show gratitude</li>
<li>Share: Look to share, educate, assist, and mentor</li>
<li>Seek diversity: Build a team that represents diverse perspectives and experiences</li>
<li>Integrity: Act the same way, even when no one is watching</li>
<li>Time matters: Time is precious, honor it</li>
</ul>
<h6>How we make decisions</h6>
<ul>
<li>Best idea wins: Debate, agree, and fully support the best idea - if fail, then next</li>
<li>PLG: Focus on product-led growth (customer-involved product development)</li>
<li>Be genuine: Every internal and external interaction is consistent with our principles</li>
<li>Equivalency: Support equivalency, not sameness</li>
<li>Deliver wow: First, meet expectations, then exceed them</li>
<li>Use it: Run our business on the products we build</li>
</ul>

To help you enjoy your experience with Atono, we have listed a few considerations and expectations to help you acclimate and to keep ourselves honest. Additional information on our Principles covering how we act, treat others, and make decisions are discussed <a href="/what-we-believe">here</a>.
Expectations for how we work include the following:
<ul>
<li>The things we value more than money include time, honesty, integrity, and trust</li>
<li>We work in teams, therefore we help one another</li>
<li>We exercise self-discipline and candor</li>
<li>You are responsible for your growth and development (and there is little comfort in the growth zone)</li>
</ul>

If you work at Atono, you&rsquo;ll hear me mention time a lot. It's our most precious resource, and while we can make more money, we can't make more time.&nbsp;
In my experience, time at work is often wasted due to ego, lack of discipline, or ignorance. Examples include attending meetings to be seen, wasting time in ceremonies, gossiping, polishing work beyond its value, and so on. Who cares? My family, my dogs, me, and I hope you.
If we assume our workload is 40+ hours per week, then any time wasted must come from personal time. Less time taking care of you or your family. Wasting time is a high crime!&nbsp;
Ok, a little dramatic there. How about this &ndash; waste not, want not.
For additional thoughts on meetings and time, read more <a href="https://www.atono.io/handbook/meetings/" target="_blank" rel="noopener">here</a>.

Remember group projects in school where you did the work and everyone else got the grade? A team is not a group. A team is a group of people who perform interdependent tasks to accomplish a common objective.
This definition suggests we need the following ingredients:
<ol>
<li>A group of people</li>
<li>People who perform</li>
<li>Interdependent tasks</li>
<li>A common objective</li>
</ol>
We know we need more to be a great team, so below are some helpful hints you may consider working on to help your team be great:
<ul>
<li>Build Trust: Always do what you say. Never leave a team member exposed</li>
<li>Communicate with empathy: Thoughtfully communicate (face to face, G-meet or Slack)</li>
<li>Serve others: Look for opportunities to help, coach, mentor or lighten other&rsquo;s load</li>
<li>Be humble: If you put the team&rsquo;s success first, you will do just fine</li>
<li>Work hard: You can be humble and still have an excellent work ethic. Be the person your team members want to partner with</li>
<li>Be disciplined: Learn to carry yourself professionally, be on time and deliver on time</li>
</ul>
If you first work on yourself, to be the best team member you can, you&rsquo;ll find you blame less, you appreciate more and your team performs better overall.

We value the ability of each person to control their feelings and improve their weaknesses. We value self-discipline. The concept often gets a bad rap since discipline can have a negative connotation. But, we know that our teams, families, customers, and investors rely on us to execute successfully.
To become the most widely used platform to plan, build, run, and support software we will need to execute better than our competition who have more money, more people and a headstart. The only viable approach is for each member of Atono to take personal responsibility to learn, improve, grow, and apply resources (time, effort) thoughtfully.

To grow into our best professional selves often we need feedback on our performance, progress, ideas, and thoughts. We practice respectful candor to help our team grow. Respectful candor is where we care more about the other person than our own ego and we&rsquo;re willing to speak directly rather than the comfort of staying silent.

Why is growth uncomfortable? Our muscles grow only after being broken down. We grow more from failure than we do from success. Discomfort is the catalyst for growth. It makes us yearn for something more and forces us to change and adapt.
Your professional growth is your responsibility. Since you are responsible, you&rsquo;ll need to build your growth plan, execute it, and seek feedback on your progress. We will provide the tools, opportunities, feedback, support, and care to assist you.

We want Atono to be the best place you&rsquo;ve ever worked. For that to be the case, each of us must contribute sincerely.&nbsp; If it&rsquo;s just a job, it will be just a job. If you work too much, you&rsquo;ll resent the job. Finding that happy medium is key to contributing to our mutual success.

If you&nbsp;must hold a meeting, here are a few game rules we've collected over the years:
<ul>
<li>Meeting size: Follow Amazon's two pizza rule if you can't feed everyone in the room with two pizzas, your meeting is too big. Invite only those absolutely needed, and let everyone else focus on their work without interruption.</li>
<li>Value of meetings: Consciously decide if asking 10 people to spend an hour is worth 10 hours of collective work. Also, remember that it's 10 hours diverted from other essential tasks. Always evaluate if the benefits of the meeting justify the investment of our most precious resource time.</li>
<li>Scheduling and length:
<ul>
<li>Duration: Meetings should only last as long as necessary, never exceeding 30 or 60 minutes. If your meetings consistently end at 60 minutes, they can likely be shortened with better preparation and a more focused agenda.</li>
<li>Timing: Opt for end-of-day when possible. Most people are less effective at 4 pm than at 9 am. By scheduling meetings at the end of the day, people can use their peak hours for the hardest tasks. This also helps us stay honest to end on time or earlier.</li>
</ul>
</li>
<li>Preparation: To ensure our meetings are as effective as possible, please provide all necessary written information in advance. Whether it's via Slack, slides, email, or video message, sharing materials that can be consumed asynchronously enables everyone to come prepared and ready to engage.</li>
<li>Forced preparation (optional): Consider adopting Amazon's quiet rule for the first five minutes for each person to review any preparation materials.</li>
<li>Objectives: To make sure the objectives of the meeting are well understood, consider what type of meeting it is. This will guide its structure and goals:
<ul>
<li>Recurring: Such as standups, sizing, and shoulder surfs where the format is well-known.</li>
<li>Brainstorming: To generate ideas, without needing to reach a conclusion.</li>
<li>Educational: You are instructing and attendees are learning.</li>
<li>Decision making: Focused on reaching a specific decision. Identify the decision maker, outline the decision process, and plan for information sharing after the decision (showing your math).</li>
</ul>
</li>
<li>Assign meeting roles: Make sure there is an assigned leader, participants, and note-taker. If actions are taken during the meeting, they should be noted and sent in writing afterward. Our default is Slack, but consider a shared document if state or future reference is needed.</li>
<li>State the rules: Are you using a parking lot? Is any idea welcome or do you need to constrain idea generation for this meeting to make a decision? Are questions interactive or held to the end?</li>
<li>Participation: If you are conducting the meeting and are seeking participation, use an effective tool to solicit it (to avoid the loudest voice being the most heard):
<ul>
<li>Solicit comments by going around the table.</li>
<li>Use anonymous methods (stickies on a board) for idea generation.</li>
<li>If unruly, consider a flag (whoever has the flag has the floor).</li>
</ul>
</li>
<li>Close the meeting: Without being rude, be quick to thank everyone for their time and close the meeting. Allow people to return to value added activities (like family time).</li>
<li>Feedback: Encourage feedback from attendees. For example: If I could have used our time more effectively, please Slack me with your feedback.</li>
<li>Follow up: We believe in showing our math, so if you've used others' time, you owe them the results of the work (Slack is fine). If actions were agreed upon, proactively deliver the results to the team so no one has to ask, Hey, whatever happened to the actions from that super fun meeting we had last month?</li>
</ul>

The most precious resource in the universe? Time. It&rsquo;s finite, and we can&rsquo;t create more of it, which is why we approach our use of time with appropriate care and intentionality.
In my experience as a CEO and former strategy consultant, I&rsquo;ve observed that organizations often use time poorly. Many companies will conduct frequent, large, wasteful meetings for the performance art of being a meeting participant. &nbsp;
Ideally, the best meeting is one not held. That said, we recognize there are some situations where meetings are highly valuable. If a meeting is necessary, then it should be conducted well. &nbsp;

At Atono, 90% of employee time should be dedicated to activities that directly contribute to our customers&rsquo; success. The remaining 10% should be used for 1:1s, administrative tasks, reviews, and essential ceremonies (standups, design reviews, shoulder surfs, retrospectives, or well-run, purposeful meetings). If you&rsquo;re consistently spending more than 10% on non-value-adding activities, please discuss this with your boss or directly with me.

Let&rsquo;s say your favorite ingredient in soup is cabbage. If I made you soup with just hot water and cabbage, would you enjoy it? Not likely. It&rsquo;s bland &ndash; lacking kick, spice, sweetness, and umph.
We live in a world of vibrant colors, sweet smells, varied sounds, deep traditions, rich cultures and, yes, spices (much like the essential &lsquo;spice&rsquo; in the world of Dune &ndash; a vital, life-enhancing element in a beloved sci-fi saga)!
So, why settle for a single ingredient in our soup? Diversity is the spice of life, and a single-note broth is boring.

Our business goal, our big hairy audacious goal, is to become the most widely used platform to help our customers bring their ideas to life &ndash; to take a dream and create an invention; to build, run, and support software services.
These customers will think differently than you. They bring their own, equally valuable, perspectives, experiences, pressures, cultures, expectations, ideas, and views. All of these may be shaped by their place of birth, race, age, creed, culture, religion, gender, orientation, or other unique qualities that make them wonderfully different from you and me.
If we are to best serve this diverse customer base, we too must learn all we can about each one. Better yet, our own employee group should be a microcosm &ndash; a special soup brimming with wonderfully spicy, salty, savory, and sweet ingredients.&nbsp;

Perhaps the most important concept of inclusion is deciding to use &ldquo;and&rdquo; instead of &ldquo;or&rdquo;.
&ldquo;Or&rdquo; implies a winner or a loser; it signifies scarcity, is binary, and forces a choice of one or the other. &ldquo;And&rdquo; implies inclusion, a growth mindset, and a world of abundance. &nbsp; Which sounds more correct? A world of scarcity and binary decisions, or a world of possibilities, growth, and potential?
At Atono, we choose &ldquo;and&rdquo;. We work as a team and we grow individually. We speak with candor and with respect.

We invite ideas, perspectives, and experiences different from our own. We seek opportunities to assist those working through disadvantaged circumstances. We don&rsquo;t want our employees or customers to ever shield their authentic selves. Instead, we look to learn from and celebrate what makes each individual uniquely themselves.&nbsp;

Customers of Atono work in all different styles. Some work entirely in the office or in physical team spaces, while others have remote teams in different time zones. Many work partially from home, and some are even mobile or nomadic, working from a camper van in remote locations. &nbsp;
We believe that Atono will help teams perform better in every work style, but we can&rsquo;t really know that unless we try to work in nearly every style &ndash; therefore, we encourage our teams to experiment with different ways of working.

Most of our team work from home on a continuous basis. Atono will provide you with the equipment you need to be successful working from your home office, including a good monitor and a great chair. If you prefer using a rented office space rather than your home, Atono can arrange that for you as well.&nbsp;

Working in person has its benefits. We believe that activities like brainstorming, planning, retrospectives, and celebrations are often better in person. We encourage teams to work in person as often as they like using Regus, Spaces, or WeWork, depending on their geographic location.

Atono supports a flexible approach for those who split their time between home, rented spaces, and the road. All employees use laptops with necessary software to ensure convenience and security. When scheduling conflicts arise, especially due to time zones, the person traveling should accommodate any inconveniences. Wherever reasonable, we&rsquo;ll work around scheduling issues.

Get a van and MiFi and hit the road. You are welcome to try it out until you miss a hot shower. Same rules apply as Hybrid above. &nbsp;

Our current common hours are 10 AM to 2 PM Pacific Time. That doesn&rsquo;t mean we work four hours a day &ndash; it means you are expected to be online and accessible during that time for questions, stand ups, retrospectives, shoulder surfs, and so on. Where special accommodations are requested, we&rsquo;ll do our best to make it happen without inconveniencing the team that isn&rsquo;t out having an epic trip.

We ask all Atono employees to be sensitive and polite to others. Be mindful of different time zones and try to schedule meetings at mutually convenient times whenever possible. Simply treat others as you&rsquo;d hope to be treated and it will work out.&nbsp;

The Atono development team uses a simple Kanban process for our development work. Our initial process is intended to allow flexibility with minimal overhead so that we can build our MVP as quickly as possible.

<div>Each story must have a single owner. The owner of a story is responsible for:</div>
<ul>
<li>Assigning the story to themselves to reflect ownership.</li>
<li>Ensuring that any subtasks necessary for the story are created. Note that this level of granular planning is not strictly required.</li>
<li>Ensuring that the story is properly shoulder surfed.</li>
<li>Ensuring that code is properly peer reviewed and merged while accounting for any merge conflicts.</li>
<li>Ensuring that the story completes the final review process.</li>
</ul>
<div>Stories and tasks will move across the Kanban board with the following statuses:</div>

The story is newly created and may still be undergoing changes as the story owner evaluates and iterates on the content prior to sending it to the rest of the team.

The story author has completed the draft of the story and is ready to solicit feedback from stakeholders. Initial requirements review and gap analysis should be undertaken at this stage by the designers and development team. Stories are prioritized for further work.

The story has a front-end component and is in need of design work from the user experience team. During this time, UX may request design reviews with stakeholders and developers. The story will move on to sizing once UX and product owners finalize an initial design. If the story does not need UX treatment, it may proceed directly to Sizing.

The story is ready for sizing by the development team. Our goal is to work stories of similar size, so the splitting of requirements into smaller stories is appropriate at this time.

The story is now in the hands of the development team. A developer may indicate that a story has been started by assigning it to themself. The story has a single owner but can be worked on by multiple developers.
The story should have a &ldquo;Shoulder Surf&rdquo; subtask and complete the surf before progressing into Test.

All work is complete. Code is available for use by users in production and any feature toggles are enabled.

Development has progressed to the point that the shoulder surf is complete and the story is ready for testing and validation by QA.

The story has passed QA and is ready for a final stakeholder review. During review, any open action items resulting from the shoulder surf are reviewed, as are any outstanding bugs. The story author will work with the development team to determine whether the story can be closed.

Competition is good for the customer. If it&rsquo;s good for the customer, then we should welcome it and participate. When the pressure is on, competition has a knack for bringing out the best in us. &nbsp;
That said, we have a very specific way of competing at Atono:

<ol>
<li dir="ltr" aria-level="1">
Tell no lies. We don&rsquo;t make up information or speculate about our competitors. Every competitor has a unique perspective and customers choose based on what suits them best. We can and should feel confident competing on the fit of our product to the customer&rsquo;s needs, rather than undermining the competition with misinformation.
</li>
<li dir="ltr" aria-level="1">
Acknowledge the contribution. It&rsquo;s easy to criticize a bespoke implementation of JIRA from 2010 still running in a data center somewhere. But that doesn&rsquo;t diminish the groundbreaking impact of Jira and Atlassian over the years. We believe our product meets the needs of the customer today, but we also acknowledge that we are standing on the shoulders of giants - so we speak mindfully and respectfully.&nbsp;
</li>
<li dir="ltr" aria-level="1">
Align solutions to needs. It's not &ldquo;our way or the highway&rdquo;, but more importantly, figuring out what is best suited for the customer. We compete on the merit and fit of our product, service, and approach with what the customer actually cares about.
</li>
<li dir="ltr" aria-level="1">
Give sound advice. It is totally fine to recommend another solution if that is the right call. For example, a prospect wants to use Atono for Development, Marketing, and Accounting project management. Atono is focused on Software Development so, perhaps Monday.com or Asana is a better fit if they require one solution for three departments with less specialization - we should advise to the best of our knowledge.
</li>
</ol>
Let's put what I said above into practice. If I was talking to a customer and they asked my opinion on Atono alternatives, here's what I would say.

Linear
The UI is quick and the search is helpful, Linear is clearly focused on software development - an excellent implementation of shortcuts. Linear&rsquo;s approach is prescriptive, they encourage you to adopt their specific development practice. For example, in the <a href="https://linear.app/method/write-issues-not-user-stories">Linear Method</a>, it says, "User stories have become a cargo cult ritual that feels good but wastes a lot of resources and time." We believe it&rsquo;s how you develop and use stories that make them useful or not useful.
Jira
Jira is mostly limited by past successes. While the customer base is an impressive 66,000, we understand that nearly 60,000 are on-premises installations, limiting Jira&rsquo;s ability to innovate. Hackernews, Reddit, and other user forums are full of broken dreams and frustrations with Jira&rsquo;s inability to innovate or improve application speed, search, or story organization.&nbsp;
ClickUp
ClickUp is a quickly growing company attempting to meet every project management use case on one system. This is a complex undertaking. Specifically for software development, our experience is that ClickUp provides a crowded UI with limited workspace. We found several of the features to be incomplete, have minor defects, or inconsistent navigation. For our team, using ClickUp was a frustrating daily experience.
Shortcut
Out of the tools mentioned, Shortcut is probably the plainest alternative. It does what it says - align product development work with company objectives - but is missing UX polish and pizazz. The focus on OKRs is an interesting direction to choose over incorporating other software development priorities.
The bottom line is the competition is not our enemy. We acknowledge they exist, we are transparent about strengths and weaknesses, and at the end of the day, they are proof that there is a market for us to serve and eventually become the most widely used application for software development.&nbsp;

One of our goals in starting Atono was to ensure our team is fairly rewarded for our hard work. We&rsquo;ve established and adhere to several key compensation principles to ensure we meet our objectives.
We&rsquo;ll discuss several of the concepts we use for compensation, including:
<ul>
<li>Wages</li>
<li>Personal time</li>
<li>Work from anywhere in the world</li>
<li>Benefits</li>
<li>Ownership</li>
</ul>

We believe in equitable compensation. For us, this means our wages typically fall within the 75-90% range of the highest payers in the market. Our compensation strategy emphasizes equity and ownership rather than being the top payer. We also avoid paying less than 50% of the top payer&rsquo;s rate since our team consists of high achievers who deserve a fair wage. We survey market salaries every six months to ensure we stay within our band and make immediate adjustments if needed, rather than waiting for the annual review process.

In addition to standard holiday leave, we offer three to four weeks of personal time off annually, with a required minimum of two weeks for self-care. Sick time is provided based on location (for example, it&rsquo;s mandated by law in British Columbia). We also allow our team to go negative on their PTO balances for epic trips. We don&rsquo;t use unlimited PTO because our experience is employees use less and they miss out on the benefits of an accrued balance.&nbsp;

We currently work from our home offices in Canada and California, allowing us to learn how to work using our collaboration tools while meeting in person periodically. Many of our current and future team members want to experience places that don&rsquo;t start with a &ldquo;C,&rdquo; so we work from other remote locations, too. We try to keep core hours for collaboration but also value our time on the road!

We believe that providing excellent family benefits is Atono&rsquo;s responsibility. Our Canadian employees receive supplemental benefits including Medical, Dental, Life, AD&amp;D, and self-care allowances. Atono pays for the top-tier plan to ensure our families are well cared for.

We strongly believe that everyone contributing at Atono is an owner, whether through shares or incentive stock options. We maintain transparency by sharing all information with employees (except personal HR and payroll details). We treat every employee as an owner and engage them in the business. We call all of our current 13-member team &ldquo;co-founders&rdquo;, reflecting their early and crucial involvement.

Plain language We provide our terms, conditions, and agreements in everyday, simple words. While they&rsquo;re based on industry-standard forms and formats, we truly think there is a higher chance of someone reading them if we keep it real. &nbsp;&nbsp;
Transparent Pricing We publish how we package, price, and discount our products and services. Each buyer may choose what they want without pressure, tricks, or fear of a wrong decision. You can always change your mind.&nbsp;
The choice is yours You should pay only for what you need. We have established our base price and each prospective buyer can pick options. In some cases, a bundle may be a better deal but that&rsquo;s the buyer&rsquo;s choice to make.&nbsp;
Everyday low pricing&nbsp; Taking a page out of Walmart here. We aim to provide lower prices on a regular basis over a long period of time. If we don&rsquo;t earn your business, we respect your right to choose. We love feedback on this, so please send it to our CEO (me, who&rsquo;s writing this article).&nbsp;
Payment flexibility There are monthly and annual plans with monthly or annual invoices available. You may pay using a generally accepted type of credit card or using an invoice. If you decide to use an invoice, we&rsquo;ll give you immediate access to the service but reserve the right to perform a credit check. If your invoice remains unpaid and you aren&rsquo;t working with us to sort that out, we reserve the right to restrict or cancel your service. We hope to never need to do that, of course.&nbsp;
You are welcome to cancel at any time. All that&rsquo;s needed is for you to pay up through the end of the monthly billing cycle. If you prepaid for a year, we&rsquo;ll refund the unused portion of your subscription within 30 days. There will be tears involved (a lot from me) but we respect your right to choose over our feelers. &nbsp;
We don&rsquo;t track you How would you feel if you walked up to the ice cream counter and this was the conversation:
You: &ldquo;Do you offer samples of your flavors?&rdquo; Ice Cream Scooper Person: &ldquo;Why yes we do! If you would like a free sample, please give us your name, address, and credit card, in case you decide to buy after tasting. Would you like a taste?&rdquo; Me: &ldquo;Uh no thanks!&rdquo;
As consumers, we don't give personal information when we're just browsing. So, please feel free to browse! If you decide to become a customer, then we'll collect the necessary information required to do a good job for you. Until then, free samples for everyone!
Upgrades, downgrades, more or less users&nbsp; Changes can be made at any time during your billing cycle (month). The changes will be effective immediately, but the charges will take effect on the next monthly billing cycle. We know there&rsquo;s a chance of people gaming the system, but we choose to trust the goodness in our customers.
Money-back guarantee You should get the value you expected. If our service, software, or team doesn&rsquo;t meet your expectations, we should give your money back. There is a (less than 15 minutes) process where we'll ask you to explain where we failed so we can see the faults in our ways and learn. After that, you&rsquo;ll receive a refund for up to three months. We hope that every other SaaS company in the world follows our lead. Build products so good that you can guarantee them. &nbsp;
There's a lot we're still learning about self-service buying. We may experiment with different strategies down the road, but the core principles mentioned above are here to stay. Our belief is that our current, future, or prospective customers should be able to learn, purchase, and use products without worry of tricks, gotchas, or confusion.&nbsp;

Self-service buying has been around for decades. Think of the simple vending machine - designed for speed and convenience. Obviously, purchasing software requires more thought than picking what beverage or snack you want, but the idea is the same: no human interaction whatsoever.&nbsp;
From the start, self-service was the way to go for Atono. Our audience is smart, knowledgeable, and skeptical. They prefer trying something out, building with it, and seeing how it actually works than talking to our "product expert".&nbsp;
We also thought a lot about self-service in consumer products. You'll probably recognize that many of your favorite consumer software businesses use this approach. Apple, Netflix, Google, Facebook, to name a few. All of them make it so easy for you to sign up and get going.
So, how does self-service buying work at Atono?
Our goal is to provide the buyer with control over the purchasing process. We&rsquo;re confident our service is worth a fair price and that the buyer has the right to the following:

We started Atono to help teams build software better, together &ndash; implying it ain&rsquo;t great today. That&rsquo;s our mission, it&rsquo;s why we&rsquo;re here.
But that statement is too vague. It doesn&rsquo;t really spell out what Atono does.
To get more specific, we go a layer deeper into our vision, or what we aim to achieve someday. Our vision is to build a software application that supports all disciplines in the Software Development Life Cycle, reflecting and promoting agile best practices.
That&rsquo;s helpful, but where is Atono heading? And how will we get there? &nbsp;
Well, in 25 years (arbitrary number to say a long time from now) our big, hairy, audacious goal (BHAG or &ldquo;bee-hag&rdquo;) is to become the most widely used platform to plan, build, run, and support software. &nbsp;

<div>Over the next two and a half decades, we know we'll need some operating principles. At times some of these will be critical, and other times not important at all. So, we'll have to pick two or three each year to prioritize and work on. They include, subject to change, the following:&nbsp;</div>
<ul>
<li>
<div>Start small and scale.</div>
</li>
<li>
<div>Maintain an open, honest business model (no games, no tricks).</div>
</li>
<li>
<div>Involve our customers in the design and creation of our products.</div>
</li>
<li>
<div>Keep our code clean (no acquisitions or bolt-on code).</div>
</li>
<li>
<div>Incorporate AI as an inherent capability throughout our products.</div>
</li>
<li>
<div>Provide applications for each development function on a common platform.</div>
</li>
<li>
<div>Grow thoughtfully into the large enterprise market.</div>
</li>
<li>
<div>Give products away to those that we shouldn't be profiting from.</div>
</li>
<li>
<div>Be known as a great place to work so we can attract the best people.</div>
</li>
</ul>
<div>Now, we have some more clues. We know why Atono came to be. We know what Atono is building, and we know that the people at Atono are daringly ambitious!</div>
<div>&nbsp;</div>
<div>This is all helpful, but it doesn't tell me what we're working on this year, or even what I should focus on tomorrow. I'm not sure which tasks are a priority and which are 'nice to haves'. So, how do we tackle this?</div>

The idea of an Objective is to declare what we are trying to achieve during a period of time. We need to measure the before and after to see if we are making progress (K=key, R=result). &nbsp;
Here are two examples of OKRs:
<ol>
<li>Improve system availability from 99.95% to 99.99% within six months.</li>
<li>Finish the new AI feature.&nbsp;</li>
</ol>
#1 is a body of work we can rally around. What ideas do we have? How are we time boxing the work? Can we rank them based on likelihood, risk, and effort? Low hanging fruit? Can we start experimenting and measuring success as we go? So &ndash; yes, we can do all those things.
#2 is not really an OKR. It&rsquo;s a project. Is the AI feature valuable? Do customers like it? Does it work? Does it impact sales? Who knows, and I guess who cares, otherwise we&rsquo;d write the objective more clearly.
Now, where do I go from here? If my team had OKR #1, we&rsquo;d use this as our North Star to brainstorm, build epics or stories, design experiments, and more. This objective would shape our work within the allocated time box or investment level. Throughout the year, we&rsquo;d perform the tasks, measure our results, and decide to keep going or stop.
As we start working on the project, suppose we find that improving system availability from 99.95% to 99.98% requires just 10% of our effort, but boosting 99.98% to 99.99% demands 90% more effort. In this case, we should challenge whether achieving 99.99% is necessary this year &ndash; perhaps 99.98% is good enough now.

<div>Each year we'll set two or three goals for Atono. Each team reviews the goals, roadmaps, and inputs, to set team or individual OKRs. Now, there are many ways for this to go wrong, so we have some hard and fast rules of the road: </div>
<div>Less is best</div>
<ul>
<li>
<div>No more than three objectives, two is preferred.</div>
</li>
<li>
<div>If you can't state the objective in 10 words, keep editing.</div>
</li>
</ul>
<div>Must be measurable&nbsp;</div>
<ul>
<li>
<div>Binary (done, not done) is ok, but not great.&nbsp;</div>
</li>
<li>
<div>Progress measurement is better (was 35% month 1, 40% month 2, now 64%).</div>
</li>
</ul>
<div>Always use your judgment</div>
<ul>
<li>
<div>When it's close enough, move on &ndash; don't be a victim to an OKR.</div>
</li>
<li>
<div>If you hit diminishing returns, find out if we can stop at &ldquo;good enough&rdquo;.</div>
</li>
</ul>
<div>You don't get paid for OKRs</div>
<ul>
<li>
<div>We get paid for providing an awesome service to our customers.</div>
</li>
<li>
<div>We create long-term value by hitting our OKRs because they help us get closer to our BHAG and you are a shareholder, so...</div>
</li>
</ul>

If you don&rsquo;t know where you are going, it doesn&rsquo;t matter which way you go.
All of this scaffolding is to help us stay on the right path. Our priorities will change over the years, but our ultimate destination remains the same.
Don&rsquo;t be intimidated by the vernacular. We have a north star.
We will get there by staying focused on helping our customers solve real problems. Each year, quarter, month, and week, we&rsquo;ll ensure what we do aligns with what will deliver success.&nbsp;

We believe in developing a vision, then a plan, defining the objectives and results to know if we are succeeding and delivering on time, every time. Our big, hairy, audacious goal is to build the most used &ndash; even celebrated platform &ndash; that facilitates the invention, construction, and improvement of software.
Our vision is to deliver happiness to the teams that build software and customers of our customers who use the software.
What we don&rsquo;t know is the eventual impact of AI on the software development lifecycle. But what we do know is the thoughtful application of it and other technologies that can be used to improve the experience, velocity, and quality of software.
Now, a few quick facts about the future of Atono.&nbsp;

Yes and no.
We raised $4 million from a closely knitted group of investors who believe in our vision and capabilities. We&rsquo;ll likely need to consider an A &amp; B round to develop and grow faster. But each round comes at a real cost and an impact, so those decisions will be thoughtfully made at the right time.

Yes and no.
Goals and directives are more like it. On the spending side, the directive is to &ldquo;be cheap&rdquo; (e.g., conserve cash) unless it involves our people. We don&rsquo;t ever want to be in a position where we need money, that would impact our velocity and my sleep quality. We aim to build a successful SaaS company with a unique revenue model &ndash; our financial goal is to eclipse $100m in annual recurring revenue by 2030.
Right now, however, we are focused on MVP, message-market-fit, product-market fit, developing thoughtful and helpful product-led growth capabilities, and so on. Much to do. We have several competitors approaching the problem in a similar way to one another &ndash; we believe that is our window of opportunity (or they are all correct and we missed the memo).&nbsp;

First and foremost, Atono must solve real problems.
We'll use AI where it makes sense, not to claim &ldquo;AI-powered&rdquo; in our marketing. We're accepting and aware that many teams build software differently than we do, so we're building capabilities to provide flexibility and speed, not an &ldquo;our way or the highway approach&rdquo;. We believe in the power of teams and collaboration, so we will stay focused on those capabilities. We also believe in and desperately want criticism of our service, the product, and the company. The goal of MVP is for teams to plan and build software using Atono. Roadmap, stories, acceptance criteria, grouping stories into epics and milestones, tracking cycles and velocity, managing defects, and experiencing a different way of using stories to get work done.&nbsp;
After MVP we plan to expand our capabilities and our approach. We'll build more features around testing, developing our automation framework, begging for customer feedback so we can iterate, building out our service capabilities, and much more.&nbsp;

<div>
<div>Please check out our other pages or use the search.</div>
</div>

Check your email to get started. Don&rsquo;t see it? Be sure to check your spam folder.