Wunder's Tech Strategy

Becoming the best mobility tech company

👀 This is best viewed at wunder.gitbook.io/tech-strategy.

Welcome!

Below are the key points from each chapter. Read the introduction to get more context.

Blue boxes with hints describe conscious biases we make.

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.

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.

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.

Want to know more? Read chapter 1. Simplicity.

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.
  • 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)

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.

Want to know more? Read chapter 2. Impact and Transparency.

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.

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.

Culture over Rules

Both solve the same problems. Culture empowers us to understand, question and grow.

Want to know more? Read chapter 4. Autonomy of How.

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.

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.

7. We are the right People for the job.

• We support personal development (e.g. 🌏 development reviews, 🌏 SMART goals and our 🌏 Eng Competency Matrix).
• 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.

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.

Want to know more? Read chapter 7. The Right People.

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 (e.g. 🌏 Microservices, preferably 🌏 reactive), 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.

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.

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.

Want to know more? Read chapter 8. Technology.

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.

Workaround over Delegation

Ownership means that we own blockages caused by others instead of halting our progress.

Improve Collaboration over Increase Headcount

Smaller teams are more efficient. We make our collaboration really efficient before throwing people at the problem.

Want to know more? Read chapter 9. Collaboration.

10. Our Organization is flexible and scalable.

• We combine elements from a hierarchical structure and the spotify model (See 🌏 Product & Eng Structure and 🌏 Engineering Roles).
• We’re happy to make exceptions to experiment, learn and improve (people > processes).

Want to know more? Read chapter 10. Organization.