Unlike venture startups, we’ve grown because our customers find value in our products.

As an engineering team, we care deeply about how our customers and end users use our product. We focus on providing the right balance between ease of use and power-user oriented features. What this means is that engineers aren't building something just because their manager says so, but instead, everyone understands the use cases and how what they're working on brings value to the end users. By using the product and understanding our customer’s goals and behavior, we come to know the technology within this scope better than almost anyone else in the industry, and can therefore provide the best suggestions and strategy for how to solve problems.

We are a service company.

We build custom solutions for our clients. Thus, we need to understand their business and their pain points to build them a solution that will work for them. We work for a lot of smaller businesses or startups that are not yet widely known. Our bigger and more well-known clients are Bosch, Zurich, DA Direkt, SAP, and BASF.

How we communicate with our clients depends mostly on how the project is organised. If the client is part of our scrum team, engineers will communicate directly with the client. In more "traditionally managed" projects, communication is mostly channeled via PMs. When it comes to scrum, we do our meetings with the client in either our office or in theirs. Mostly, we try to rotate so that the client is regular visiting our offices as well. That seems to help to build trust in us when the client can "see" us work.

Since our marketing strategy is based on mouth to mouth propaganda, we make sure to deliver the best service to our clients.

Our customers are both developers and every day web consumers.

We are an open-source project with over >7k community developers who contribute to our code. We have a Slack channel that has >4k members and we regularly interact with people in the channel. We actively seek feedback from the community, our customers, and view feedback as a necessary component in order to build a successful product.

Our mission is to bring the best in plus-size fashion to a population that’s been underserved for far too long.

Women sizes 14 and up are over 50% of the population of the US, yet on average they spend significantly less on fashion than their lower sized counterparts. The lack of product variety, poor/demeaning in-store experiences, and societal pressure all contribute to this. These are the problems we are solving for this customer every day at Dia. Every feature we build, every machine learning system we create, and every flow we optimize is aimed at improving the the customer experience. Engineers are fundamental to this process, and are expected to be looking at the data and thinking about the customer for each thing we build. We even style boxes for our customers as part of our onboarding!

Out of 200 something employees at reddit, less than 10 have left in the last 6 months.

Yes, the company at large has high retention and no, we certainly can’t claim the same for our mobile team. After all, we’re a relatively new team and none of us have been here that long to begin with. That being said, we put a lot of attention in measuring engagement from our team members. We use Culture Amp to solicit honest feedback, capture the employee perspective, and use measurable results to identify areas of improvement and track our progress. We care a lot about making this a fantastic place to create, learn, and work and our numbers reflect it.

We chose this as our first value because that’s what the data revealed, and is a value shared by the clear majority of our engineering organization.

(By the way, our data team ensured that we sampled our key:values in randomized order so there would be no artificial clustering!)

Our engineers are organized into multiple agile teams. A product owner/manager handles the product research, defines and prioritizes feature stories, and communicates with customers, while the scrum team of engineers execute the lion’s share of the work. These teams are supported by the quality, design, data, and techops teams. To that end, each product owner ensures that efforts are aligned with business/customer values, with each sprint sized appropriately to that team based on its historical performance. Rarely do teams overcommit, enabling a us to run marathons over releases than burning out over sprints.

Work hours are relatively flexible with pre-agreed standup times and scrum meetings, dependent on the internal planning by the team. Working together remotely is standard fare as we’re empowered using modern collaboration software (JIRA, Zoom, Github, etc.). We have four offices (New York, Toronto, Long Island, Lexington) across two different countries (US and Canada) and a handful of entirely-remote contributors.