> For the complete documentation index, see [llms.txt](https://wunder.gitbook.io/tech-strategy/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wunder.gitbook.io/tech-strategy/master.md). # Wunder's Tech Strategy 👀 This is best viewed at [wunder.gitbook.io/tech-strategy](https://wunder.gitbook.io/tech-strategy/). ## Welcome! Below are the key points from each chapter. Read the [introduction](/tech-strategy/introduction.md) to get more context. {% hint style="info" %} Blue boxes with hints describe conscious biases we make. {% endhint %} ## 1. We turn complexity into *Simplicity* to maximize our impact. * We **minimize surprises** for our co-workers, customers and future selves to increase speed and quality. * We **think and decide rationally**, informedly and unemotionally. * We make ourselves and each other aware of trade-offs. * We challenge and reflect on how we do things to always improve. {% hint style="info" %} **Consistent** *over* **Perfect** The second-best solution can be our ideal if its more consistent with our environment and therefore keeps our environment simple to navigate. {% endhint %} {% hint style="info" %} **Reuse** *over* **Customize** *over* **Reinvent** We take what already exists and try it out. That gives us real-world data to continuously adjust our approach. Depending on scope, we resolve conflicts based on the tech strategy and input from squad members or tech managers. {% endhint %} > Want to know more? Read chapter [1. Simplicity](/tech-strategy/1.-simplicity.md). ## 2. Our output is *Impact and Transparency*. * We continuously push to increase our productivity. * * We do 80:20, i.e. we look for smart ways to go 80% of the way with 20% of the effort. * We don’t waste time discussing [🌏 easily reversible decisions](https://fs.blog/2018/04/reversible-irreversible-decisions/). * We educate stakeholders on how they positively/negatively impact our productivity. * We build **transparency** by … * … asking and mutually explaining our business goals and processes. * … explaining the hidden and sometimes counterintuitive truths of engineering (e.g. larger teams are sometimes slower) {% hint style="info" %} **Transparency** *over* **Output** A key challenge is smooth collaboration between teams in a fast-moving environment. Keeping stakeholders accurately aware of our output resolves a main cause of friction and builds strong trust. {% endhint %} > Want to know more? Read chapter [2. Impact and Transparency](/tech-strategy/2.-impact-and-transparency.md). ## 3. We do *World-Class Engineering*. * Quantity ≠ quality. Less code is better & productivity can’t be measured in lines/hour, but in business impact. * We make conscious decisions regarding what quality level we need in what context. * We build quality (DoR, pull criteria, collaborative test case definition) and don’t offloaded it (e.g. to QA) * We value observability, and fail early in order to adapt more effectively. * We come together for fun and knowledge (Code Cafés, Lunch Tech Talks, Eng Reviews, Town Halls, meetups, hackathons, conferences, offsites). > Want to know more? Read chapter [3. World-Class Engineering](/tech-strategy/3.-world-class-engineering.md). ## 4. Strong teams have the Autonomy of How. We empower everyone to identify problems and continuously improve everything about our environment. Engineers make dozens of decisions every day that define output, speed and quality. Their decisions make the difference between minutes and months of delivery time. Those decisions are more complex and more impactful than e.g. meeting attendance. {% hint style="info" %} **Culture** *over* **Rules** Both solve the same problems. Culture empowers us to understand, question and grow. {% endhint %} > Want to know more? Read chapter [4. Autonomy of How](/tech-strategy/4.-autonomy-of-how.md). ## 5. Wunder is *Global*. We embrace cultural and personal differences because they make us stronger. Diversity helps us to create space to be awesome. > Want to know more? Read chapter [5. Global Perspective](/tech-strategy/5.-global-perspective.md). ## 6. We create *Space to be Awesome*. Space to be awesome … * … is filled with inspiring people, clear and flexible structures, helpful tools and interesting problems to solve. * … is a safe space that’s diverse, inclusive and respectful. * Diversity makes us stronger. We cherish people regardless of their origin, gender, sexual identity, age, etc. * We reinforce inclusion by learning from and appreciating each others’ differences. * We encourage each other to regularly give candid, constructive feedback. > Want to know more? Read chapter [5. Space to be Awesome](/tech-strategy/6.-space-to-be-awesome.md). ## 7. We are the right *People* for the job. * We support personal development (e.g. [🌏 development reviews](https://wundercarpool.atlassian.net/wiki/spaces/WUN/pages/93618458/People+Development+-+Engineering), [🌏 SMART goals](https://wundercarpool.atlassian.net/wiki/spaces/WUN/pages/94044396/TalDev+-+Engineering+-+SMART+Goals) and our [🌏 Eng Competency Matrix](https://docs.google.com/spreadsheets/d/1nig9rTidgzVbPDLlktiX9dhxyhkIeMp8QL-pj_AwAdc/edit#gid=0)). * We hire the right people by extensively assessing candidates’ technical, cultural and mindset fit. * We stay relaxed and positive in the face of challenges. * We’re curious and excited about new opportunities and are flexible to change assignments if necessary. * We rally behind our company mission and team goals. {% hint style="info" %} **T-profiles** *over* **Monothematic experts** *over* **superficial allrounders** We strive for depth in at least one technology and broad general technical understanding. That way we can collaborate in other languages and ecosystems and become better at comparing technologies while remaining up-to-date experts in one field. {% endhint %} > Want to know more? Read chapter [7. The Right People](/tech-strategy/7.-the-right-people.md). ## 8. We use *Technology* to build great software that we can easily live with. * We use separation of concerns and inversion of control to cutting down complexity. * We choose languages/tools/libraries based on utility, quality, ecosystem maturity, longevity, our experience and our ability to maintain them. * We demand written documentation of feature sets from the product team (and indirectly from sales). * We work with prototypes and MVPs. We understand and communicate the differences. * We structure our applications to support team, feature and customer growth. By building [🌏 modular structures](https://www.youtube.com/watch?v=4Y0tOi7QWqM) (e.g. [🌏 Microservices](https://genehughson.wordpress.com/2014/06/04/more-on-microservices-boundaries-governance-reuse-complexity/), preferably [🌏 reactive](https://www.youtube.com/watch?v=GcMlxkFf6zk)), we optimize for throwing away and replacing code without affecting the whole building. * We move faster by writing tested software. * We know that properly doing TDD allows us to deliver features faster and reduces follow-up cost from bugs. * While planning features, we decide on how to test them. * We never skip tests for business logic. {% hint style="info" %} **Maintainability** *over* **Speed** *over* **Beauty** To understand what good software is, we need quick customer feedback. The only thing more important than that is that we remain able to run and change what we build. Hacky solutions are okay as long as they’re isolated and easy to replace. {% endhint %} {% hint style="info" %} **Complementary Products** *over* **Interconnectivity** *over* **Single Product** Our customers are diverse and don’t (yet) demand our products to be integrated. This will change in the future. In an evolving market, the best way of allowing future integration is to build proper products and not to try anticipating what integrations will make sense. {% endhint %} > Want to know more? Read chapter [8. Technology](/tech-strategy/8.-technology.md). ## 9. How we *Collaborate* minimizes friction and overhead. * We take end-to-end ownership for team outcomes. * We actively seek information and speak up if we lack clarity. * We don’t hide problems and we value people who bring them to the spotlight. * We help each other proactively, regardless of team, function or seniority. * We talk about requirements, scope and proposed solutions throughout the work stream to avoid over-engineering. #### We make our communication as simple and efficient as possible. * New key information is discussed, aligned and contextualized in a vertical’s leadership before shared with the team. * We provide context in communication to minimize back-and-forth. * Our meetings have clear goals and deliverables. * We record decisions and action items. #### We stand on the shoulders of giants when doing agile. * Every squad has a definition of ready (DoR) and done(DoD) for User Stories. * All work on the product happens in tickets. {% hint style="info" %} **Workaround** *over* **Delegation** Ownership means that we own blockages caused by others instead of halting our progress. {% endhint %} {% hint style="info" %} **Improve Collaboration** *over* **Increase Headcount** Smaller teams are more efficient. We make our collaboration really efficient before throwing people at the problem. {% endhint %} > Want to know more? Read chapter [9. Collaboration](/tech-strategy/9.-collaboration.md). ## **10. Our *****Organization***** is flexible and scalable.** * We combine elements from a hierarchical structure and the spotify model\ (See [🌏 Product & Eng Structure](https://miro.com/app/board/o9J_kymX1bo=/) and [🌏 Engineering Roles](https://wundercarpool.atlassian.net/wiki/spaces/WUN/pages/160858373/Engineering+Roles)). * We’re happy to make exceptions to experiment, learn and improve (people > processes). > Want to know more? Read chapter [10. Organization](/tech-strategy/10.-organization.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://wunder.gitbook.io/tech-strategy/master.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.