LinkedIn

large_7ed7cc7c-23cd-4e4b-8662-46f9e53283e8.jpg

medium_7ed7cc7c-23cd-4e4b-8662-46f9e53283e8.jpg

small_7ed7cc7c-23cd-4e4b-8662-46f9e53283e8.jpg

thumbnail_7ed7cc7c-23cd-4e4b-8662-46f9e53283e8.jpg

7ed7cc7c-23cd-4e4b-8662-46f9e53283e8.jpg

Marty Cagan’s recent comments on Software Agencies came as a bit of a surprise, but I was pleased to see such insights from someone so influential in our industry. Marty has done a great job capturing the reality, and his perspective prompted me to delve deeper into the topic, drawing on my decade of experience representing a Software Agency.

Marty provided a “fair enough” assessment of Software Agencies. If you haven’t read his piece, I highly recommend doing so before diving into my comment.

https://www.svpg.com/the-product-model-in-outsourcing/

My experience extends beyond co-creating an agency—I’ve also collaborated with other agencies across numerous projects. While Marty focused on the challenges from a client’s perspective, I want to shed light on the agency’s side and explore why so much money is wasted on outsourcing. 

I'm sharing my thoughts because we ([Appunite](https://appunite.com)) are on a mission to transform how software houses operate. While we are halfway there, I wanted to highlight the challenges we've identified, the progress we've made, and what's next.

## Specification to make sure work is delivered correctly

In most cases, Clients approach agencies with a specific solution in mind. **Agencies, in turn, are eager to play that game. Even if a Client doesn’t have a specific solution, they often frame the conversation as if there’s a one-size-fits-all answer that can be estimated, specified, and delivered on time.**

Agencies generally prefer scoped work, and the market reinforces this preference. The dilemma then becomes: should we invest time in gaining more context or craft an offer similar to what other agencies provide?

**Sales teams often rush to provide estimates because it’s a key argument in client discussions.** Developers, on the other hand, hesitate to commit until they fully understand what needs to be built. Best case scenario, this disconnect leads to workshops—not for discovering the problem but for- again, specifying the solution. Unfortunately, this is the path many agencies take when clients don’t have detailed specifications.

We’ve been there too. A few years ago, we wouldn’t involve developers in the conversation until the designs were finalized. The design process was a separate entity, occurring between our business representatives, the Client, and the designer. Once the design was approved, we’d assemble the team. Looking back, I feel a bit of shame—but it was a learning experience that taught us how *not* to do things.

## High demand for developers has significantly impacted the sales process

Having a solution in mind, Clients seek the best quality-time-price ratio. The window for exploring conversations beyond the standard scope—such as providing specifications, team size, lead time, and cost—is often very short, especially when other agencies are quick to offer these details.

This issue isn’t just the Client’s fault. It’s a consequence of how agencies grew, especially when the demand for developers was high. Some agencies didn’t feel the need to change. Recently, I witnessed a panel discussion where software house founders openly stated they didn’t want to get involved in product and business—they just wanted to deliver the software and move on. This mindset is prevalent, and it eats away at the industry. 

**Almost every agency talks about the impact they can have on Clients, but when you dig into the details, you find that everyone interprets “impact” differently. A good way to gauge this is to ask an agency how they define the success of their collaboration.**

## **Agencies often focus solely on development competencies, missing the bigger picture**

Buzzwords like MVP and POC are still thrown around. Many Clients believe that when they reach out to an external agency, they need to have all the exploration done, and a solid specification in hand. They think this ensures smooth onboarding and speeds up development, but that’s rarely true. Often, decisions aren’t documented, aren’t backed by research, and are more like a stakeholder’s wishlist. If Clients don’t have this ready, they expect it to be prepared before the collaboration starts.

## Getting beyond coding is hard

I’ve seen that many agencies lack the competencies and skills to deliver value beyond coding. They lack product and design expertise and, most importantly, the right mindset for product development. This approach is widespread in software agencies and has impacted the entire industry. One of the biggest challenges in creating an outsourcing company capable of taking ownership of the problem is assembling the right team. Many developers don’t want to engage in deeper discussions; they prefer to focus strictly on the technology, expecting the “rest of the work” to be handled by non-technical people. Over the years, we’ve learned to identify such individuals, but the extent of their impact continues to polarize developers.

## Software house as a place for product people

For product-oriented people, a software house isn’t usually the first choice. You’re more likely to find a project manager than a true product manager in such environments. Although the variety of projects can be tempting, being outside the Client’s organization makes it harder to have a significant influence.

So, if agencies can’t play the role of Product Manager, they fall back on being good at delivery. The problem is that even though they can deliver a solution, it often doesn’t address the root cause. The return on investment is rarely positive. In such situations, agencies may try to shift the blame onto the Client, claiming they delivered exactly what the Client wanted, on time. However, I don’t know a single Client who returns under these circumstances, even if the agency thinks they did a great job—they didn’t.

## Product vs Client—who to serve

This dilemma is very real. An agency striving to make a meaningful impact must constantly balance between satisfying the Client who hired them and serving the users of the Client’s product. Unfortunately, not every client sees these as aligned goals. **Challenging stakeholders might ultimately benefit the end-users, but it could also lead to the agency losing the contract.** This tension often depends on how the agency defines its value. If sales take precedence over actual results, the agency may be more inclined to agree with whatever the stakeholders want to build, even if it’s not in the best interest of the users.

This dilemma is akin to the challenge faced within a product company, where one must choose between pleasing stakeholders and serving users. However, the twist here is that as an external agency, you’re always at risk of being cut off more easily. This is why some teams, fearing the loss of a client, may instinctively avoid raising critical issues.

## Timesheets

Timesheets are still very much in play. Both Clients and agencies continue to rely on them. Clients appreciate the reassurance that the hours they’ve paid for are indeed being spent on their project. Meanwhile, agencies use timesheets as proof that the client is receiving what they’ve paid for. As I mentioned earlier, most collaborations operate on a time and material basis—a model designed to avoid ownership.

I recall a time when most projects were billed at a fixed price, but agencies soon realized that the carefully crafted scope would inevitably change during development (who would have thought, right?), leading to delays in delivery and even financial loss for them. To mitigate this, agencies adopted the time & material model. This approach allows them to take on less ownership and sidestep accountability, even at the delivery level. The only thing it truly guarantees is that the developer spent time working on the project.

## There is still much that needs to change

The market has evolved in a positive way in that aspect, there are fewer projects per agency, which makes them rethink the way they operate. Many agencies have adapted their approach, but the industry as a whole still bears the mark of past practices. It’s challenging to distinguish between those agencies that genuinely understand the changes required to meet the realities of today’s product-building environment and those that merely use these ideas for marketing purposes.

While I agree that Clients need to rethink how they cooperate with agencies—how they search for partners, outsource technology, and so on—I believe there is even more for agencies to address if we are to see these changes take hold on a broader scale.

## So what should the cooperation with a modern agency look like?

We've been testing different approaches, and while we can't yet say we've found the perfect solution, we have a good sense of what it might look like. We've already made progress in certain areas of our operations, while other parts are undergoing extensive testing with both existing and new clients. Some aspects remain aspirations that we're eager to pursue.


![Infograhic 2.jpg](https://strapi-appunite.s3.eu-central-1.amazonaws.com/Infograhic_2_89c0bfd3ef.jpg)


## Tailored approach for immediate value delivery

We place great emphasis on how we initiate conversations with clients. Rather than relying on traditional sales presentations, we prioritize understanding the client's needs from the outset. While this might seem straightforward, transitioning the conversation from discussing solutions to exploring the underlying problem, context, and constraints is often challenging. At this stage, we focus on discovery rather than education, as we recognize that we don't yet have enough information to offer solutions confidently. The conversation becomes valuable when the client uncovers new insights or realizes we can deliver more value than initially expected.

We swiftly involve our experts to analyze the context gathered during the initial call, identifying areas where further exploration is needed. If we detect gaps in the client's understanding at the product level, we connect them directly with our Product Growth Manager. This marks the beginning of our consultation process, where we aim to provide value while deepening our understanding of the client's business.

We have moved away from conducting large workshops that clients pay for, as we've found that the value delivered in these sessions is often insufficient. Instead, we meticulously document the problem, context, and constraints—not the solution—ensuring that everyone involved stays aligned as the information evolves.

Our organization follows a mission-command approach. In simple terms, we define a mission for the team that outlines the problem, context, and constraints. The mission owner then prepares a backbrief, presenting a general solution approach to confirm the team's capability to deliver. This approach is integral to our sales process, where the goal of discovery is to craft the most accurate mission based on the client's needs.

Two key teams are involved at this stage, reflecting our organizational structure. The Sales team focuses on answering:

- Why are we building this?
- What impact will it have on the client's business?

Meanwhile, the Opex team (our internal term) ensures we understand:

- What do we need to build?
- How are we going to build it?

This collaboration forms the foundation of the offer we present to the client. Any gaps identified during discovery are noted in the mission as "known unknowns." When the client is ready to proceed, this mission serves as the handover document to the team forming phase, which I will elaborate on further.

Our process is continuously evolving. After every client interaction, regardless of whether we sign a contract, we assess how we could have better understood the client's problem. There's no rigid process dictating the number of conversations needed; instead, our curiosity drives us to understand as much as possible to define the best problem statement at that time.

## Comprehensive product development expertise

Our teams forming process is focused on assembling the best possible team for the mission at hand. We ensure that the team has the capabilities to drive the mission forward and solve the problem. Over the years, we've learned that gaps in expertise can significantly slow progress or even halt it entirely. We've drawn from concepts in *Inspired* and *Empowered*, combining them with our experience to deliver beyond just code. While technology remains at our core, what others might call supporting roles are crucial to our approach.

It's worth noting that we also collaborate with clients who bring their own product managers, which is entirely fine with us. Our priority is ensuring we have the competencies needed to create a cross-functional team capable of addressing the problem.

## Commitment to outcome ownership

Problem-solving is deeply ingrained in our culture. Even internal initiatives are regularly reviewed for outcomes. A significant milestone for us has been the intentional selection of our team members. As I mentioned earlier, some developers prefer to focus solely on delivery rather than continuous discovery. We don't hire those who set such boundaries. We expect everyone to understand the desired outcome and commit to achieving it. Everyone, including those in strictly technical roles, is evaluated based on the impact they have on our clients.

## Iterative process guided by user feedback

We place great importance on clearly communicating the outputs we generate each week. We even have an internal channel, "what-we-shipped," where teams across various projects share their achievements. However, we emphasize that success isn't defined by the release itself—the release is just the beginning. We prioritize having direct access to users. We are constantly refining our user interview skills to improve. The common goal across our growth and service departments is to generate the most positive ROI cases for our clients, which is why we validate our work at the outcome level.

## Seamless transition to internal teams

Many companies hesitate to outsource due to concerns about vendor lock-in or losing context when transitioning to an internal team. We understand that circumstances change, and there are times when having an internal team is more practical. We don't resist this shift. In fact, we have a history of assisting clients in recruiting internal teams and ensuring a smooth transition of knowledge, resources, and responsibilities.

## Value-based pricing

We are currently experimenting with value-based pricing models. With a history of taking ownership through joint ventures with our clients, we've even invested in products we believe have potential, allowing us to take ownership at a deeper level. Our ongoing experiments involve correlating the results we generate with the price our clients pay. We believe this approach represents the future, and while we're still learning, we're eager to explore this direction further.

## Money-back guarantee

This is another experimental component of our system. As we move towards value-based pricing, we're also exploring ways to share risk with our clients. We want our teams to be goal-oriented and focused on delivering expected results. While we don't always have full control over achieving the goal, we're open to sharing the risk with our clients. We only commit to missions when we are confident in our ability to deliver. The general idea is that partnering with us increases the likelihood of success compared to going it alone. We're willing to take on greater risk and even offer a money-back guarantee if the desired result isn't delivered. While this isn't something we standardize yet, we're open to discussing it.

## Summary

While there's still much to explore in our journey to build the service we've envisioned, we're not waiting for someone else to discover the way forward—we're taking the initiative and embracing the risks along the path. Although some aspects of our approach might seem familiar, we've already made significant changes to deliver greater value to our clients. If you're interested in being part of this journey, reach out to us. We're open-minded and ready to collaborate on crafting solutions that truly work for clients like you.

21.08.24 _ The software agency business model is broken.jpg

large_21.08.24 _ The software agency business model is broken.jpg

medium_21.08.24 _ The software agency business model is broken.jpg

small_21.08.24 _ The software agency business model is broken.jpg

thumbnail_21.08.24 _ The software agency business model is broken.jpg

A lot Needs to Change in Outsourcing to Software Agencies.

Imagine us sitting in a bustling café in Dubai, the aroma of Arabic coffee in the air, as I share some insights from the heart of Europe, Poland, where I lead Service Delivery at Appunite. I sense your curiosity and perhaps a few apprehensions about collaborating with a software house miles away. So, let me address those thoughts and paint a picture of what it’s like to work with us.

### **Deep Product Expertise: Beyond Regular Outsourcing**

What sets us apart is our deep product expertise. We’re not your regular outsourcing team; we’re partners in the true sense. We invest time in understanding the problem and the business context you operate in. Our approach is to translate your business goals into an actionable product strategy, quickly validating assumptions. We have the tools to speak directly with the users, taking full ownership of the digital product. We focus on being a true partner, leading the full product development with a keen understanding of your vision and needs, rather than just being executors.

### **Tailoring Solutions: Addressing Unique Needs**

Every founder, every vision is unique, and we understand that. Our approach is tailored to address the specific needs and aspirations of each partner. 

We listen, we adapt, and we craft solutions that are not just technologically sound but also resonate with the market and the end-users.

It’s about creating a product that’s a true reflection of your vision and a solution to your users’ needs.

We have experience in coordinating local third-party providers. Working with your internal teams is something we excel at.

### **Bridging Distances: Direct Flights and Small Time Zone Differences**

Firstly, let’s talk about distance – it’s closer than you think! With direct flights from Dubai to Poznań, meeting up is easy and affordable. 

We understand that sometimes it's more effective to see how operations are running on the ground. Are you looking to showcase your product at one of the numerous expos happening in Dubai? We've got you covered.

Plus, the small time zone difference means our working hours overlap significantly, making real-time communication a breeze.

### **Legal Ease: Contracts Under UAE Jurisdiction**

Navigating the legal landscape? We’ve got it covered! We’re able to sign contracts under UAE jurisdiction, ensuring a secure and compliant collaboration. It’s like building a bridge between our lands, with strong foundations in mutual legal understanding.

### **Communication at Its Best: Organized, Transparent, and Continuous**

Communication is our forte! Important updates, discussions, and information are always documented on platforms like Slack or Notion. It’s like having a digital diary that keeps our collaboration organized and transparent. We believe in continuous overcommunication – keeping the channels open, ensuring clarity, and addressing queries.

### **Weekly Demos and Sync Meetings: Keeping You in the Loop**

Every week is a step forward! We run weekly demos, showcasing the progress and milestones achieved. It’s like a sneak peek into the evolving masterpiece. Additionally, our weekly sync meetings are a platform to discuss priorities, align our goals, and ensure we’re on the same path.

### **Gaining Domain Knowledge: Tools and Mindset**

Understanding your vision and market is crucial for us. We’re equipped with the tools and mindset to gain domain knowledge, delving deep into the nuances of your industry. It’s like learning a new language – we immerse ourselves, ensuring the solutions we craft resonate with your audience.

### Understanding of Arabic Market

With our extensive experience and long-standing presence in the Arabic market, we possess a deep understanding of how to effectively develop products that are specifically tailored to meet the unique needs and preferences of the region. We have successfully implemented RTL (right-to-left) applications and websites, showcasing our expertise in catering to the language and cultural nuances of the Arabic-speaking audience. Our team is well-versed in the principles and trends of design, ensuring that the products we create are not only visually appealing but also aligned with the latest industry standards and user expectations.

### **English-Speaking Team: Breaking Language Barriers**

Language is no barrier in our collaboration! Every member of our team speaks English, ensuring smooth and clear communication. It’s like having a conversation with a friend – easy, understanding, and enriching. Of course you have direct access to the whole team.

### **Embracing Cultural Differences: A Successful History with Dubai Founders**

Cultural differences? We see them as opportunities for growth and learning! We have a successful history of working with founders in Dubai, embracing the cultural diversity and turning it into a strength. Our approach is to understand, respect, and celebrate the unique aspects of each culture, ensuring they enrich our collaboration rather than become a blocker.

### **Conclusion: Your Partner in Crafting Success**

So, there you have it – a glimpse into the harmonious collaboration that awaits you with Appunite. With the ease of travel, legal clarity, organized communication, cultural synergy, deep product expertise, and tailored solutions, we’re here to bring your digital dreams to life. If you’re ready to embark on this journey, let’s chat over another cup of coffee and start crafting a story of success that’s uniquely yours.

large_ashim-d-silva-CwJb7ly-iqc-unsplash.jpg

medium_ashim-d-silva-CwJb7ly-iqc-unsplash.jpg

small_ashim-d-silva-CwJb7ly-iqc-unsplash.jpg

thumbnail_ashim-d-silva-CwJb7ly-iqc-unsplash.jpg

ashim-d-silva-CwJb7ly-iqc-unsplash.jpg

Discover how UAE startups are harnessing the power of Polish developers. Dive into the journey of product creation, bridging Dubai's visionaries with Europe's top tech teams.

Bridging the gap between Dubai's startup vision and tech execution. Dive into the world of UAE product innovations, powered by Poland's dedicated developers.

The Future of Tech: How UAE Startups are Scaling New Heights with Polish Partnerships

Crafting Global Success: The Synergy of UAE Visionaries and Polish Tech Prowess

# Stop wasting money on MVP, build to get customers instead.

Many startup founders wonder whether to acquire customers or build a product first. The question is whether it's better to build a product that no one uses or have a customer ready to buy, even if you're not yet ready with the product.

It's important to start with an acquisition strategy. Don’t build a product until you know how to reach your potential customers. If you can't get your first 10-100 leads, having a product ready won't change that.

Some people take shortcuts and start with an MVP because they've heard it's how to minimize risk and spend less while validating their idea. However, in reality, this is only half true. The execution of an MVP often turns out to be terrible, as instead of building a Minimum Viable Product, founders tend to build a product lacking only a few "nice-to-have" features. They end up investing dozens of dollars into building software that does not bring their idea any closer to creating a running business. 

You must stop considering your MVP as working software that solves the problem. Start thinking about your MVP as the quickest way to get out to your target group and learn as much as you can as fast as you can about their behavior in correlation with the problem you're trying to solve. The MVP is supposed to provide you with information about the problem, solution, and your customers, ideally on those three elements. You can't learn that without having real people using it. So instead of spending 2-3 months building a product, be smart. Find a way to get your idea out within a week and spend the rest of the time iterating it repeatedly.

Nowadays, there are dozens of low-code, no-code, or out-of-the-box solutions to get that learning started. Here are some examples:

- Build a landing page to experiment with communication, see how people behave on your website, and use A/B tests to see what converts better.
- Use tools like Google Analytics or Posthog to learn more about behaviors, demographics, and test pricing.
- Create social media channels or blog posts to attract your target group by serving them valuable content, interacting with your followers, and learning what would make them a customer.
- Skip the automation part and run the complete flow manually.
- Use no-code tools to let people interact with your product, but keep the main flow manual. It can act as a substitute for an MVP.

If you fail to learn before wrapping up the full development team, you will not only burn your runway for development but also waste time on development while you start learning about your customers. 

So what's the way I would choose? In the early stages, I would rather hire a part-time partner with development skills who can get our idea to daylight within days or weeks. Later, we can study the results and iterate on them on a daily basis until we get confident enough about what we need to build.

That approach not only saves your investment in early stage, but also helps you to validate plenty of assumptions you are making around your startup, including if you are the right person to solve the problem. 

Why I am sharing this?

As a former developer and entrepreneur-wannabe, I learned that having good ideas and coding skills is not enough to build a successful startup. Investing in code caused me a lot of stress in the past, even though it wasn't a financial burden. However, I eventually learned that there are other ways to go about it.

In the past 10 years, I have observed a similar approach from technical and non-technical individuals. While it may have different nuances, it is crucial to prioritize learning about the customer before developing the product.

large_kevin-ku-aiyBwbrWWlo-unsplash.jpg

medium_kevin-ku-aiyBwbrWWlo-unsplash.jpg

small_kevin-ku-aiyBwbrWWlo-unsplash.jpg

thumbnail_kevin-ku-aiyBwbrWWlo-unsplash.jpg

kevin-ku-aiyBwbrWWlo-unsplash.jpg

As a former developer and entrepreneur-wannabe, I learned that having good ideas and coding skills is not enough to build a successful startup. Investing in code caused me a lot of stress in the past, even though it wasn't a financial burden. However, I eventually learned that there are other ways to go about it.

How to avoid spending to much money on MVP. Avoid expensive MVP development. Validate Startup idea with customers first.

Stop wasting money on MVP, build to get first customers instead.


As a startup founder, the delays in your software development projects can be a major headache. But instead of finding excuses, it's time to uncover the root causes and act on them effectively.

Never forget, technology and business should work hand in hand for your startup to thrive. You, as a founder, are a critical component of your tech team and have the power to steer the direction.

Let's delve into how you, as a founder, can identify and rectify the causes of software development delays.

## Clarifying Expected Outcome
In software outsourcing, a common issue is the disconnection between those setting business goals and those implementing the solutions. As a founder, it's your responsibility to bridge this gap.

### Symptoms:

Developers are unclear about the purpose of a feature.
The need for a feature is communicated without context or rationale.
Decisions cannot be made without your input, leading to delays.
The Source of Delays:

The disconnect often means the team operates within a narrow frame of thinking, focusing on the given solution rather than the broader business objective. This limited view can lead to confusion and delays when unforeseen situations arise.

### Your Role:

Keep the focus on the end goal. Help your team anticipate potential roadblocks and remain resilient. Remember, your aim is to have technology serve your business goals, not vice versa.

Consider adopting a hypothesis-based communication strategy. For instance, "If we build Z, we can expect Product Metric Y to increase by about 10%, contributing to our Business Goal X".

[![empowered_cta.png](https://strapi-appunite.s3.eu-central-1.amazonaws.com/empowered_cta_2db0fe1c90.png)](https://empowered.appunite.com?utm_source=appunite-blog&utm_medium=blog-cta&utm_campaign=delays&utm_id=blogpost-inefficiencies)

## Implementing Timely Feedback Loops
A team isolated for extended periods to develop a product is a recipe for failure. As a founder, your role is to ensure consistent feedback to keep the team on track.

### Symptoms:

Weekly discussions of deliverables are absent.
Founders or stakeholders seem disconnected from the process.
The team lacks the support of a domain expert.
The Source of Delays:

A lack of feedback can cause the team to stray from the right path, leading to unnecessary rework and delays.

### Your Role:

As a founder, provide the tech team with regular feedback or enable their direct access to users. Ensure they validate their work weekly at different levels – concept, design, and solution. If there's a gap in validation, fill it with your domain knowledge.

## Boosting Team Performance
Merely hiring a group of specialists doesn't guarantee a high-performing team. As a founder, your active involvement is crucial in maintaining team productivity.

### Symptoms:

The team fails to recognize their low-performing periods.
Discussions about team performance are absent.
Stakeholders seem uninformed about the team's challenges.
The Source of Delays:

Without regular performance reviews, the team fails to adapt to changing circumstances or identify under-performing members. This can lead to low morale and productivity, thereby causing delays.

### Your Role:

Initiate feedback sessions and performance metrics to monitor the team's progress. Conduct regular retrospectives to identify and discuss any issues.

Questions to consider during these sessions:

Are we meeting expectations?
If not, why?
What can we improve?
Are we delivering on time and maintaining quality?
As a founder, ensure the team is aware of their performance and is motivated to improve continuously.

In summary, as a startup founder, you have a crucial role in addressing software development delays. By taking proactive actions, enhancing communication, providing regular feedback, and motivating your team, you can steer your project towards a timely and successful completion.

At Appunite.com, we stand with founders like you, ready to provide expert guidanceto help you transform your vision into a digital reality. Let's join hands to overcome software development delays and keep your startup on the fast track to success.

As a startup founder, the delays in your software development projects can be a major headache. But instead of finding excuses, it's time to uncover the root causes and act on them effectively.

Struggling with software development delays in your startup? Discover actionable strategies that startup founders can implement to boost communication, enhance feedback loops, and improve team performance. Start overcoming delays today.

How to Tackle Software Development Delays: A Practical Guide for Startup Founders

# 

We believe that hypotheses help teams and individuals communicate more efficiently. Here is an explanation why.

Communication within a team is usually straightforward. We understand the goals we want to achieve and have a direct impact on the direction we choose. Ideally, we move in the same direction and at a similar pace, creating a small ecosystem that is familiar to us.

Things get complicated when we look at larger systems like organizations. There are multiple teams and even more individuals. The ultimate goal might be understandable, but there are factors that make communication harder. We have different perspectives because our daily work is focused on different areas. We have different skills and knowledge, we specialize and do different things. We move at various paces and experience different things. But we still rely on each other.

Every time we come up with a change that affects not only our team but other parts of the organization, we put ourselves at risk because, due to our limited perspective, we might not see the consequences in other places. The natural way to minimize this risk is to ask for feedback. But here's the catch: If we ask for feedback on the change, we might receive poor feedback or none at all. Why is that?

Because it's hard to give feedback on someone's actions without knowing the intention. What's the desired outcome someone is trying to achieve? Looking at the sole action, others might not feel the importance of it and might deprioritize it.

When we use hypotheses to communicate, we give others a way to provide feedback not only on our actions but also on the direction we choose and the approach we take.

If I understand what someone is trying to achieve, it's easier to express:

- If this seems to be an important topic from my perspective
- If the direction is accurate
- If the chosen approach is optimal

I can also imagine:

- What consequences it might have for me, my team, or the organization
- What can go wrong
- How I can support it
- Why this is important

Hypothesis-driven communication helps us communicate better between teams. It helps our projects be more successful by better expressing our intentions and painting a better picture of the change we want to make.

large_nicolas-thomas-3GZi6OpSDcY-unsplash.jpg

medium_nicolas-thomas-3GZi6OpSDcY-unsplash.jpg

small_nicolas-thomas-3GZi6OpSDcY-unsplash.jpg

thumbnail_nicolas-thomas-3GZi6OpSDcY-unsplash.jpg

nicolas-thomas-3GZi6OpSDcY-unsplash.jpg

Every time we come up with a change that affects not only our team but other parts of the organization, we put ourselves at risk because, due to our limited perspective, we might not see the consequences in other places. The natural way to minimize this risk is to ask for feedback. But here's the catch: If we ask for feedback on the change, we might receive poor feedback or none at all. Why is that?

Why do we use hypothesis at all?

---

Our culture wasn't fully created by design. It's a result of random events as well as conscious choices. Each choice comes with tradeoffs. Some are already addressed but others may still need to be tackled. These choices make our organization a place where not everyone can fit in, but if you do, you are able to achieve amazing things. Let me share some of the choices we've made and the tradeoffs they bring.

**We don't tell people what to do, so they need to find their own fit.**

**Gain**: If you find your own passion that aligns with our goals, you'll get plenty of autonomy. You can act as a partner, not just an employee. You define your impact.

**Tradeoff**: It's not easy to discover your passion, nor is it easy to define how it will help our mission. This can be frustrating for less experienced people who still need guidance.

**We treat code as a tool.**

**Gain**: We move fast when we need to. We make it scalable when needed. We reuse if that's the most optimal way. We see creating software solutions as an investment that has to be adequate for the return.

**Tradeoff**: We expect the teams to understand what we are building and what impact it will have on the business. We expect the teams to focus on the wider context. We expect to choose right tools for the problems instead of building fancy solutions.

**You are responsible for your own growth.**

**Gain**: You can steer where you want to be and how fast you want to grow.

**Tradeoff**: You have to be transparent about it and ask for feedback. If you don't, you might find yourself going in a different direction.

**You shape your career by making a bigger impact, not by changing titles and earning badges.**

**Gain**: You don't need a title to act. If you make an impact, you'll be invited into bigger topics easily.

**Tradeoff**: If you perceive your progress by gaining different titles and seeking authority, you'll be frustrated.

**We prioritize mission-driven teams over setting clear boundaries between roles.**

**Gain**: We want to be pragmatic in solving problems, so we bring the best people for the job.

**Tradeoff**: The same role in different places might look different than here, which can put you outside your comfort zone.

**We share context as widely as possible.**

**Gain**: We don't create unnecessary proxies. Teams talk directly with clients. Stakeholders provide context often. You can easily access the information you need.

**Tradeoff**: Sometimes there's too much information, so you have to selectively choose what can help you achieve better results and what to ignore.

**We communicate on public channels.**

**Gain**: We avoid communication silos. By default, information is public unless it needs to be private.

**Tradeoff**: You have to carefully choose communication channels. We avoid communicating on DMs and private channels, which might feel awkward at first.

**We prefer sensible defaults over processes and procedures.**

**Gain**: We don't want to limit ourselves by having processes and procedures created by design. You can break each process and procedure if it makes sense. If you don't have an idea, you might follow sensible defaults or create them if they don't exist.

**Tradeoff**: Sometimes you might feel lost and take ownership of choosing a different path.

**We expect high ownership.**

**Gain**: You have the autonomy to solve challenges.

**Tradeoff**: You're responsible for choosing the path you follow. We expect you to lead topics you own.

**We expect you to admit when you don't know.**

**Gain**: Pretending you know is wasting others' time, and we don't want that. We embrace saying, "I don't know."

**Tradeoff**: It takes time to get comfortable with saying "I don't know," and it can be frustrating when others say it and you think they should know.

**We don't accept saying, "It's not my job."**

**Gain**: We have each other's backs. We don't ignore problems just because they happen somewhere else.

**Tradeoff**: You might find yourself leading topics until you find another owner.

**We're eager to accomplish our mission.**

**Gain**: You might get inspired only if you want to.

**Tradeoff**: Even though it's unclear sometimes how to do it, we talk about it boldly. Not having a clear path might be frustrating sometimes.

**We don't accept complaining.**

**Gain**: You might get inspired by others' approaches to tackling issues.

**Tradeoff**: Instead of complaining, we expect you to do something about it.

**We embrace failure.**

**Gain**: We learn much quicker if we bring failures to the surface. You might learn from others' mistakes.

**Tradeoff**: Sometimes you might contribute to the failure, and we want to be transparent about it so others can learn.

**We want decisions to be made as close as possible to the problem.**

**Gain**: You're expected to make decisions.

**Tradeoff**: You can't expect top-down decisions. Instead, you receive context instead of decisions.

**We don't compare ourselves to our competition.**

**Gain**: We prefer to get inspired by the best. You'll hear a lot about Netflix, Google, and Apple. Even though our reality is different, we believe our approach is similar.

**Tradeoff**: We might be doing some things worse than our competition.

**We expect everyone to contribute to the mission.**

**Gain**: You're invited to be part of the journey. We listen to everyone, no matter how long you've been here.

**Tradeoff**: If you're looking for a place to just write code or sell software, AppUnite isn't it. You'll be constantly stretched to work around the mission.

**Skills matter, but attitude is a game-changer.**

**Gain**: By being curious and not accepting things, you might bring a lot of value, no matter what skills you have.

**Tradeoff**: Skills are useless if you can't create value with them. We don't tolerate ignorance, even if you're the best specialist on the market.



large_colton-duke-QRU0i5AqEJA-unsplash.jpg

medium_colton-duke-QRU0i5AqEJA-unsplash.jpg

small_colton-duke-QRU0i5AqEJA-unsplash.jpg

thumbnail_colton-duke-QRU0i5AqEJA-unsplash.jpg

colton-duke-QRU0i5AqEJA-unsplash.jpg

Gains and Tradeoffs of Appunite Culture

Appunite’s mission is:

# Become a #1 partner in building software products and revolutionize the way software is designed, developed, and delivered.

 

But what does that mean? 🤔 

How do you measure if you are already #1? 📈 

What does it mean to revolutionize the way software is designed, developed and delivered? 🧑🏻‍🎓 

Finally, 

#### Is this the right place for me?💞

#### How can you, as an individual, contribute to it?🤯


---

Our conviction is that technology is a tool for solving real-world problems. 

#### → We focus as an organization on growing our expertise in building product teams, 

#### → so we can consciously apply better and better approaches to the businesses of our Clients

#### → so they can succeed, providing us with more challenging problems at the same time

#### → so we can succeed, finding new challenging problems in future

Being a #1 partner is our North Star 🤩, we believe we can get there, but what’s more exciting, we enjoy the journey 🧗. The journey is where your involvement can make the biggest influence. It’s essential for our growth.

## What’s the idea behind it?

We hire both experts and people without any professional experience. We are proud of it. I joined the company without any commercial background 10 years ago. 

How is that even possible? We believe that curiosity and dedication drive growth. We love to give a chance to people who feel they can bring something valuable to the company. 

We trust, that people can make judgments about where is the place they bring the biggest value. We optimize to create an environment where they can shine. 

As with everything, it has its own downsides. The tradeoff is that we won’t tell you what to do. 

We believe you will find out what’s the most valuable, most fun, and what moves the organization forward. 

## So how do you actually build influence in Appunite?

In other words, how did you develop your career in Appunite? Not by earning another point in your skill-set matrix. Definitely not by changing the role next to your name. 

You do that, by changing the angle you look at things. 

You start with your team, as this is the smallest organization unit. By constantly looking at how you can improve the way the team is working, you become an influencer. Then you start to think about what would make your team successful over a longer period of time. What actions should we take to be in a better position later? 

Then you change your angle from the team perspective to something bigger, it can be either the technical tribe, a bigger team, or the company. You look at things with an even longer perspective. 

Lastly, you start to think about how I would like the World to see our Company. What actions can I take to change that perception.

One example can be expanding your emerging practices to other teams. Do you see something is working really well? Share with others, and explain your approach. Do you deal with some problems? Let others know, they might experience the same, maybe you can group around it and solve it together. Do you see some key information missing during the process? Raise that issue, and suggest a solution. Day by day improve your environment. 

You are moving on two dimensions, like in the matrix below.

![Screenshot 2022-10-06 at 15.49.18.png](https://strapi-appunite.s3.eu-central-1.amazonaws.com/Screenshot_2022_10_06_at_15_49_18_3bfb6d7e70.png)


## How should I know what's needed?

Start with defining your own compass. What do you truly believe in, what are the values you care. Think about what drives you, what feels fun to do. No matter what job you are assigned to, you are empowered to change Appunite. 

Look around. What makes you upset, what stresses you, what feels ineffective. Start with small steps to make your space a bit better. The worst thing you can do is to be focused on something, staying passive at the same time. It will frustrate you, and frustrate others. You don’t have to have ready solution. Sometimes it only takes to pursue the issue. Gather a wider context. Understand why it is the way it is or just raise the importance of the issue in the Organisation. The solution might come later. We do have good tools to do that. You can either raise an issue and explain your perspective in one of the Teams Challenges boards, or if you don’t know where to address your concerns you can create the Business as Usual card in order to identify a working group around it. Again, try not to generalize problems, and don’t project your team’s problems to the whole organisation. Try to solve it locally, if you can’t ask for help.

## Ideas are ten a penny while the ability to execute counts for a great deal more

We don’t force anyone to do things this or that way. Meaning that having a good idea is not enough. It requires effort. The tradeoff is that you actually need to expose the benefit of the change, and convince coworkers that it’s worth putting energy into it. The reason we do so is that none of us own a monopoly on knowledge. We avoid top-down decisions.

We really value doing progress more, than being on the move. Meaning that we look at the outcomes of the initiative, not just actions around it.

## How I can introduce the change?

The best way to expose the benefit of the change is by doing a small experiment. In your local environment, the team probably. If it succeeds, share the result, if it’s convincing, the rest will follow. That is the natural way of leading.

If you are wrong, no worries. That is one of the reasons we tend to do experiments on a smaller scale. Wrap up the results and let others learn from your failure. Decide what next.

## So does this mean that everyone can do whatever they want?

Not really. One of our core values is to give and be open to feedback. You got an idea, gather the feedback from people around you, people who the change might affect. Be curious about what they want to say. No traction? Rethink your approach. Maybe you identified the need inaccurately. 

 

But if you truly believe in something, fight for it, till you convince others that this is the way to go. By changing the environment, you build trust. Trust can level up your actions even higher. The way we look at the trust is perfectly envisioned here:


[https://www.youtube.com/watch?v=kJdXjtSnZTI](https://www.youtube.com/watch?v=kJdXjtSnZTI)

## How it can look in the practice?

We put effort into letting our teams find their own purpose, that supports our mission. We encourage you to start the conversation in your team about “what we are actually doing here”. Again, looking at a longer perspective makes you think a bit differently. We do software, so our teams can easily say that their job is to deliver a project. But what do we have from it in a long perspective? The project can end tomorrow, for various reasons. We try to think what are the outcomes of it. What we learned, what people we trained, and what leaders raised from that team. That is what moves us as an organization toward our North Star. That’s why it is beneficial to find common ground between team purpose and individual goals. Not only it helps with motivation, but it ensures that we grow people during the time of a project.

 
![Screenshot 2022-10-07 at 08.37.44.png](https://strapi-appunite.s3.eu-central-1.amazonaws.com/Screenshot_2022_10_07_at_08_37_44_8a2bc28b5b.png)

## Is it a good place for me?

You probably already can get a grasp feeling who we are. Let me demystify who we are not. 

We do not tell people what to do. 

We do not tight ourselves to our roles and duties.

We don’t limit ourselves to the here and now. 

We don’t have all the answers.

We don’t standardize things until we see benefits from them. 

We don’t follow blindly our competition.

We don’t build leadership around authority.

large_clark-tibbs-oqStl2L5oxI-unsplash.jpg

medium_clark-tibbs-oqStl2L5oxI-unsplash.jpg

small_clark-tibbs-oqStl2L5oxI-unsplash.jpg

thumbnail_clark-tibbs-oqStl2L5oxI-unsplash.jpg

clark-tibbs-oqStl2L5oxI-unsplash.jpg

Being a #1 partner is our North Star 🤩, we believe we can get there, but what’s more exciting, we enjoy the journey 🧗. The journey is where your involvement can make the biggest influence. It’s essential for our growth.

How do you actually contribute to the Appunite’s mission?

Have you ever felt like everybody in your team is working like free atoms? That you put effort into something, and nobody supports it? Some people do things, but when you ask them why they do it they can’t answer. It happens to all of us. Here are a few tools that can help you and your team align efforts around things that really matter.


### Working Agreement


One of the easiest forms to express the hygiene of our day-to-day work. I usually start with an explanation of why we want to create such a document for our team. I start with one, or two rules that feel important and encourage the rest of the team to discuss what content we put there.

It contains behaviors that we expect from each team member; what is undeniable required in communication; what rituals we have in the team; how we treat each other. 

What I recommend is to keep it simple. Add only those points that we feel are essential and avoid dreaming. The best option is to write the practices that the team is already doing. If it's a new team we suggest falling back to the Organization's practices.

A working agreement is an important tool, especially working remotely. 

Here are some points that our teams include in the Working Agreement:

-  If it is possible, we have the **camera turned on** in daily meetings and we are **fully focused** on what others are saying. The daily meeting should have a short and concise form, max. 15-20 minutes. 
- 
- We communicate on public channels, avoiding direct messages and closed groups
- 
- We don't leave problems - If things don't go our way and we finish the workday, we share the status of our job.
- 
- I would like to put one additional point at the top of the working agreement:
- 
- We agree to feedback on each other if we see a violation of this agreement.


### Team Purpose

Our teams live in a few dynamic environments. Things are changing quickly. We succeed and we fail daily. Sometimes we don’t have control over things that happen to us. That causes a lot of stress, especially for those who like to see the plan for the future. 

One reason we prefer to build long-lasting teams in Appunite is to find a team purpose that helps them to be more resilient to unexpected things. The purpose should be the result vector of individual needs and impact the organization itself. 

Purpose especially helps when you make decisions that might have a big impact on the team. I like to always ask myself and the team if this decision moves closer to the purpose or not.

We want all of our product teams to work in the spirit of getting better in building products. They twist that in their own way and those who have a firm belief in what they want to achieve develop their members faster.

Your team members should identify with the purpose, so they can support it. That’s also a good rule if someone is a good match for your team.

> Find people that passionately believe in making the world a better place. Because if you don't truly believe in making the world a better place —then you may choose to make decisions that aren’t necessarily making the world a better place.
> 

Example purpose: 

***We want to share our extreme ownership approach by growing our team in the spirit of the same culture.***

***We want to be the best mobile team in Poland.***

### Problems and Challenges

Powerful. An important part of fulfilling the purpose of the team. Every team member might have their own perspective on what is currently blocking the team or what is the opportunity that we focus on. 

Making the team aware of its problems, opportunities and challenges is crucial, when we want to use our energy in a smart way. Having the same perspective on what is the next priority for the team allows for moving faster. We concentrate the energy of team members on the same thing. 

### Individual contracts

Something that I love. When a new person joins, we take a moment to express our expectations from both sides, the new joinery and the team leader. We discuss those, create some kind of contract between us and we get back to it from time to time on 1on1s. We usually have some expectations above „writing a code” or „doing quality checks”. It's good to express those even if they seem to be obvious.

I recommend sharing those expectations with the entire team. It makes it easier to understand what each member is thriving for, therefore supporting him/her.

Example: *Having your seniority in mind, I would expect you can guide other members of our team in terms of X.*


>*Side note: We recently started using a tool called **Business as Usual**, to synchronize the efforts across all the teams in our Organisation. We create a hypothesis in a single document - why we feel something is worth investing the effort, what effect we expect, and what needs to happen to make the initiative successful. We track all the discussions, changes, and progress there, so everyone can understand the status and why we do it at all.*

**I'm curious, what tools do you use in your team to build alignment in the team?**

medium_Screenshot 2022-08-01 at 14.54.26.png

small_Screenshot 2022-08-01 at 14.54.26.png

thumbnail_Screenshot 2022-08-01 at 14.54.26.png

Screenshot 2022-08-01 at 14.54.26.png

team building, leadership, crossfunctional teams, alignment

Piotr Bernad