Amsterdam Standard

streamlinehq-page-under-construction-product-1080 1.svg

Something went wrong

A developer, software engineer, programmer, (however you like to call them) is usually a pretty unique person. As Alfred once said "Some Men Just Want to Watch the World Burn".
Developers on the other hand want the world to run smoothly, seamlessly... like clockwork.

I think comparing to a clockwork mechanism is on point. A developer wants to build small little springs, levers and gears. Set all of these components in a solid housing, apply some tender, love and mineral oil for things to move smoothly. And at the end of the day, the best part of it all, is when a dev can wind that single crown on the side of the clock and watch the entire mechanism come to life.

Each piece moving in sync and unison with another, one gear passing information to another. That is the endgame, that feeling is what a coder expects after hard days, weeks or even months of work.

Over the years of working with devs, being a dev, working with Product Owners and getting familiar with Product Owning I can tell that the business side and the programming side don't usually see eye to eye.

### So what kinds of tasks or processes demotivate developers?
And how to avoid them


Imagine working on a wedding cake for at least a week. A large 3 layer cake. with icing and rose petals and handmade figures adorning the top. And minutes before the wedding you are asked to dispose of it. No-one saw it, no-one tasted it. Sure you got paid, but why do the work if it's going to be thrown away.

Unused code is time spent planning, building, testing, while somewhere along the way the higher-ups decide to cancel the idea and never publish the code. This includes code that is used only for a while, as I call it temporary code. Things that are manually added then removed after a certain amount of time. Convert manual work to a manageable and automated version, devs love that.

##### Avoid temporary features with existing functionality
Most of the time temporary code is just a gimmick, an alteration of an existing functionality. Instead of asking a dev to make a new kind of modal, or a new kind of form, just use the existing ones you might already have. Especially if it's something temporary that will expire in a week? a month?

The moment a developer has to type in a start & end date of a feature in the actual code, you know you've gone too far. Automate this. Invest the time to make repetitive events or features manageable and have the content team activate or deactivate them when needed.

This excludes AB testing, that by nature is temporary code. That being said even AB tests should be prepared in an MVP (Minimum Viable Product) or in a "fake it till you make it" kind of way. You are proving a concept, don't build 2 fully functional versions as an AB test. Use the AB test results to build the final version of a feature.


Best case scenario is when everyone knows the end picture of the product and everyone has a clear path towards it. But in a real world that is almost never the case. CEO's, PO's, or even clients don't really know what they want and what will bring the most value.

Way too often the development team is not involved in the long term roadmap or plans for the future. With a shortsighted backlog a developer doesn't know how to prepare for the end game.

Bad preparation can lead to redundant code or POCs (Proof of Concepts) that burn before seeing the light of day. See #1 Redundancy.

You'll soon see that most of these demotivators are closely related to each other and they intertwine.

##### We need to build a laser that can cut through foil

A dev gets asked to build a laser that can cut through foil, but only the foil, not anything underneath it. So a developer starts to build it, but somewhere along the way the PO comes back and says we need a grabber too, so the vice can hold the item while the laser cuts the foil.

A month later it turns out a huge machine was built that delicately holds a piece of candy while a laser cuts and extracts the contents from inside. If you told a dev you want to open a candy bar, he'd take it, grab the zigzagged part and just pull away the foil.

This is an exaggeration ofcourse but sometimes thats what requests without knowing where we're going look like.

Involve the dev team, or a representative in roadmap discussions, plan short and long terms plans, have one solid and unified vision of the end game. You will save a lot of time, money and stress. Often there are easier solutions to a problem.


#### Spend more time planning, and being sure of what you want. Constant spec changes and "slapped on" features are not maintainable

Closely related with #1 and #2. Some tasks demotivate a developer because they sound wrong, or are badly thought out or are just redundant. In situations like these I bring out the good, old question machine. As a dev just start asking questions, like "should this also be for logged out users" or "what happens if case B, or case C". If you get answers and there is enough data supporting the feature, then maybe the goal was misunderstood.

Usually though the answers are monosyllabic grunts of dismay which force the task giver to go back to the drawing board and figure out all the loose ends. Keep inline with your end game goals.

Writing code is not like building a house, where you first see some foundations being poured, then walls being erected, followed by a roof and windows, doors. Often during development of an application there is background work that is being done. The end user or stakeholder doesn't see this and wrongly assumes someone is being lazy or not pulling their weight.

This is more about educating the stakeholders about how code development works. Not everything is done on the frontend, and not everything is always a tangible feature. Trust in your dev team and with proper scrum methodologies the higher-ups can always be up to date with current progress of features.

##### House keeping and plain old boring work

The next 2 are demotivators that popped up often in my polls. But they are more about house keeping. Chores that just have to be done even if it's not any fun. Even in a normal household taking out the trash or cleaning the bathroom is something most people would like to skip. But they still need to be done.

Personally this one doesn't demotivate me but it is possible that getting an issue ticket that can't be reproduced sucks out your passion. Following the steps the tester used and not getting the same error is somewhat soothing (because it's not happening for everyone), but also frustrating (because you'll need to fix it some day). Knowing there is some kind of combination of actions that cause this can keep you up at night.

Many times it's just bad luck, a network delay or interruption, some other process lagging on the end users device, or on the server, an outdated device or just plain user error.

There is no magic remede for this apart from more tests, QA testing, testing on older and slower devices or traditionally blame it on a fluke and hope there are no more issues of the same nature in the future.

This is the definition of a chore. Code should be documented and described so that team members and new onboarders have an easier time getting to grips with all thats happening in a project. This has a lot of added value but is often overlooked or ignored either because no-one wants to do chores or #4, its invisible progress.

As boring as it can be, writing documentation is just something developers need to do. And higher-ups need to understand its value in the long term. Along with automated testing it's the easiest components of an application to exclude and save costs on.

Try to share code documentation amongst the team, everyone should be pulling their weight and not have 1 person dedicated to going chores. Documentation can be done in small shifts to make the chore seem shorter and easier to do.

##### Coding is not a production line

Your software, your developers and your entire organisation should be striving towards making an autonomous machine. IT is not a factory, it's not manual labour. You wouldn't want a watch where you'd need to manually turn a gear every once a while for it to keep running?

A happy dev is one that knows what the end game is, that is well informed and has time to figure out the best path towards a solution. A good dev can assist in decision making, and can also determine where cost optimisations can be made. A mature dev knows that even the boring tasks, the chores to do around the house are also part of the game and adapts to it, not complains and avoids doing it.

Low hanging fruit and "quick wins" give immediate results but many times also bring tech debt. Give a little thought to the graph in this article. 

![geeks-and-repetitive-tasks-02-1024x622-1 (1).png](https://public.amsterdamstandard.com/geeks_and_repetitive_tasks_02_1024x622_1_1_b5e19901e0.png)
_Image courtousy of https://outfunnel.com/pipedrive-automations/_

Top 6 things that demotivate a developer

Today, as a summary of this year, we’d like to share with you our project management best practices.


In our honest opinion, this is a mandatory meeting to have a good start on cooperation at the very beginning of the project lifecycle. In Amsterdam Standard, this meeting is usually organized by the Delivery Manager (or Project Manager). As a first step, make sure all the right people are invited and everyone is fine with chosen date and time. Next and crucial: prepare an agenda, choose a person who’ll lead the meeting (DM/PM), and ask your customer what topics he’d like to have covered. 
What exactly should be found in the agenda - it’s up to you and your needs, but when it comes to our recommendations it’s worth mentioning:
- Target market
- Product presentation
- Product/business goals
- Communication channels that will be used by the team
- Project governance, discuss company work culture
- Project responsibilities
- Risk assessment

When you’re done with a kick-off meeting we recommend going a step further. For bigger projects and teams where the project responsibility seems to be fuzzy, we’d like to show you the PM responsibility matrix. Invite relevant people to the meeting, based on who will bring the best input, and discuss which parts will be managed by who. Defining them at the same beginning of the project will help you avoid ambiguity in the later part of it. 

![IMG_2625.jpg](https://public.amsterdamstandard.com/IMG_2625_5d21566825.jpg)

What is best about project management? Even if you know the methods, have experience, and have successfully delivered many projects, it’s still all about the learning process. 

There are no perfect projects, perfect teams, or ideal project managers, but what’s most important is that we can learn from each other, discuss the cases and share the know-how. 

As a Holidays gift, I’ve put together a list of the best project management practices that our project managers team has learned over the two years of working with Amsterdam Standard teams. 

Probably known by every project manager, so it’s just a reminder to use this powerful ‘tool’. It’s good practice to make notes after extra meetings happening in your team (outside of regular Scrum ceremonies). How to make them well organized?
- always include the date and participants
- mark down goals (to have clarity on what is expected to be achieved)
- discussion points (or another form of notes that are important but are not necessarily action points)
- action points (clear follow-up actions to be taken after the meeting) - don’t forget to assign the owners!

Sometimes a good supplement to meeting minutes or project documentation might be a decision log document that gathers all the most important decisions in one place, with easy and quick access.

![Project-Management-best-practices-Dokumenty-Google.png](https://public.amsterdamstandard.com/Project_Management_best_practices_Dokumenty_Google_64fb32c9d3.png)

There’s no good project without a great and close-knit team. Make sure to plan some integration activities not only among developers but also with the customer, product owner, and all the stakeholders engaged daily in the project. 
Some ideas:
- Online beer + games - examples: 
1. Charades, e.g. scribbl.io;  
2. Q&A’s - questions “this or that” or “would you rather..”;  
3. 9 free online team building games for remote teams  )
- PubQuiz between teams - a trivia of team-related questions/photos between teams;
- Creative hackathons - night hackathons with beer&pizza;

Besides regular retrospectives with your team, it’s nice to celebrate the end of a bigger project phase (or ending the whole project). Some tips from us:
- Orgaznie a separate meeting to underline it’s an extra event;
- You can use some retrospective tools to have a nice summary and discussion, but in the big picture; you can prepare it in another way than usual (use timeline, prepare milestones, memories, make it more interactive)
- Make it more ‘festive’, focus on good things and improvements.
This kind of event should help you build a nice culture of celebration with the team, not only focusing on delivering and then rushing forward again.

As we mentioned in the point above, it’s always a good time to celebrate. Preparing a year-end summary would be a nice Holidays gift for your customer and team. The goal of this meeting should be to wrap up the passing year, celebrate the achievements, and have fun.

**What could be prepared for such a meeting?**
- Company accomplishments wrap-up
- New projects on the Client side
- Growth
- New people hired, new departments formed
- New markets
- Roadmap summary


**Team accomplishments wrap-up:**
- A number of sprints and retrospectives closed
- A number of story points burnt
- Most important releases
- A number of new people in the team
- The most important features
- The most important improvements
- Most important team achievements

**Extra content:**
- Some funny team photos, internal jokes :)

**Year-end retrospective - in big picture.**

**Goals for the new year or Q1.**

When we’re finishing the project, cooperation or someone is leaving the project it’s always nice to have a ‘goodbye meeting’, which seems to be a nice and obvious idea, but believe me - doesn't happen so often. Of course, the agenda depends on the situation and relations - and what’s more important - always ask everyone if they’re ok with it. If so, you can include below parts:

- Knowledge sharing session - someone is leaving, so this person can underline what was responsible for, and share the most important aspects and information;
- A QA’s style session could be organized - so questions are asked to a specific person leaving to about the most important things before they leave;
- If the atmosphere is good, you can ask team members to prepare some nice memories or quotes for the person who’s leaving, or just a couple of sentences saying ‘thank you for common work together;
- If the project comes to an end, you can use some ideas from above point Year-end summary, enriched with some nice team moments and accomplishments plus documentation and access handover.

I hope you find the above best practices useful for your projects or cooperation. Remember, it’s based on our Project Managers' best-practice, feel free to adjust the ideas to your needs.

Project Management - best practices

Companies, managers, and team leaders constantly seek easier, faster, more efficient, and innovative product development and problem-solving...

Companies, managers, and team leaders constantly seek easier, faster, more efficient, and innovative product development and problem-solving. Besides casual brainstorming and discussions, there are a lot of more creative methods that come in handy, one of them being Event Storming.

Once you get familiar with this method and its benefits, next time you will be less surprised after entering a room full of colorful sticky notes. Stay with us to learn what is Event Storming and its main principles.

Event Storming is a workshop-based method that helps quickly identify issues and processes in the domain of software development. Its roots reach the DDD (Domain-Driven Design) approach. It helps teams to see the big picture of the situation and reveals its complexity and status, as well as helps to clarify needs and goals. 

As Event Storming accelerates group learning and finding non-standard, alternative solutions and improves the efficiency of teamwork, it’s commonly adopted by both startups and more mature organizations. Needless to say - it can be also truly fun, stimulating and engaging, and much more satisfying than traditional methods. And all of this can be achieved with the simplest tools you can even think of - colorful sticky notes.

**What can you use Event Storming for?**

- Building business modules
- Assessing the health of existing business models or products
- Defining or highlighting your project’s goals, needs, challenges
- Visualizing the potential solutions and brainstorming
- Identifying bottlenecks and areas for improvement in already existing products and processes
- Getting a shared vision or common understanding of the discussed topic.

On the contrary, Event Storming may not be suitable for creating deployment plans, designing documents, or planning the coding process, and it’s not a substitute for a UML diagram, flow chart, architecture diagram, or any other tools used in the implementation. Event Storming is much more about improving teamwork that drives creative thinking, exchanging ideas, and running productive conversations and discussions.

Although Event Storming can be used in nearly every industry, it perfectly corresponds with the specifics of IT projects.


To get a better understanding of how Event Storming can contribute to your daily work, think about the last project you completed. What did developers have to do to understand the business domain, and build the system that would correspond with the client’s needs? Most probably, they had to chat with a dozen of team members such as domain experts, architects, designers, and more. As a result, the knowledge got too diluted, distorted, and fragmented to be able to build a complete, functional model.

Event Storming can respond to these challenges and minimize the risk of misunderstandings in the project. With this method, you can accelerate communication and involve everyone in the problem-solving process.

**So what are the benefits of using Event Storming in IT projects?**

- Common vision. The team working together can go deeper into the discussion and achieve mutual understanding, even between technical and non-technical stakeholders and participants.
- Accelerated group learning. Thanks to this collaborative method you will achieve rapid modeling without the need to become a DDD expert.
- Fast development. Event Storming increases software development efficiency and helps to define goals, objectives, and principles, and to form business models in a reduced time. 
- Boosted creativity. Event Storming drives innovation and allows for a much more inspiring product development process than standard techniques do.
Integration and cooperation. Working together can be fun, and help team members to achieve more. Thanks to hands-on experience, everyone can participate and interact, which leads to increasing morale in the team and more satisfying results.
- Efficient problem-solving. Breaking the process down into simple terms helps to identify bottlenecks and find alternative solutions much faster.
- Group learning. During the Event Storming session, everyone is involved in the process, which stimulates group work and learning by doing. It also involves exchanging knowledge between domain experts.
- Low costs. The process is informal and inexpensive. To organize an Event - Storming workshop, you need paper, sticky notes and pens that you can most probably find in every office.

An Event Storming session is typically a one-day event preceded by the right preparations and involving the proper people. There are obviously different approaches to the method, however, we’re gonna provide you the information on the most classical one.

At Amsterdam Standard, we typically start the workshop with a short discussion about the purpose of the session. We make sure that all participants are prepared to use the technique, and have the essential knowledge. We start with pre-defining the problem and the flow of the session. With the right preparations, we usually manage to map the complete business process during a single workshop.

**1. Right people**

The people involved in the Event Storming session are: 

- _Participants. _The process must involve both domain experts and people who came to ask questions, and be based on cross-department cooperation. Typical participants are C-level employees, stakeholders, business domain representatives, managers, developers, team leaders, designers, and testers, depending on the project’s specifics and objectives. Everyone should be equally engaged, related to the problem, and able to contribute. This usually means involving 6-8 people on average.


- _The facilitator._ To keep an Event Storming session effective, it needs to be led by an experienced facilitator or trainer who plays an essential role in the process. They provide participants with instructions and moderate the entire workshop to make it smooth, clear, and valuable. What’s important, they don’t disrupt the process and don’t interrupt the participants’ vision, but only control the flow and make sure it goes in the right direction.

**2. Right space**

To run an effective Event Storming process, you need to prepare the working space.  Start with collecting multicolor sticky notes, markers, and a big piece of paper or a vertically oriented flipchart that will allow you to arrange the notes on the timeline. Make sure you have enough working space, and that you will not be limited by the dimension of the room or paper - as you will prepare a big map containing ideas, expressions, and questions written on sticky notes, the modeling space should be as big as possible. We also advise removing chairs and tables
Let’s also shortly discuss the colors of sticky notes. To make the process effective, they should appear in different shades. Of course, you can agree on your own color code within your team, but the most basic colors used in Event Storming are orange, blue, and green. To ass more context to the model, you can also use yellow, purple, pink, or red. So, make sure you have enough sticky notes in different colors before setting up the place. 

**3. Right communication**

The language of communication during an Event Storming workshop should be as clear as possible, and understandable to everyone. For example, if you typically work with developers, but for this specific project, you need to engage stakeholders without technical knowledge, make sure that your team members will be understood. To ensure this, avoid technical jargon or explain the most important keywords right before the process.

**4. Business domain**

A good understanding of the business domain is essential in effective Event Storming sessions. There are three main components of the Event Storming model that help to break down the discussed problem:

_Events_

Identifying domain events is the first step in the process. Domain events are all events that happen and trigger reactions. This step helps to understand the principles and functionality of the designed processes or system and is a critical step of the Event Storming session.

The events, defined and written down on sticky notes, should be then organized in chronological or sequential order on the timeline. The recommended color of the sticky note is orange, and the phrases should be formed in the past tense to highlight that there are events that actually happened.

The examples of events are:
- An account was created.
- An e-mail was sent.
- Tickets are sold out.
- The payment was completed.

_Commands_

Once you have your domain events defined, it’s time to evaluate each of them and find answers to the question: why did this event occur? Evaluating each of them will help you to define their causes and the factors that triggered them called commands. They can also represent user interactions with the designed system and are typically written on blue sticky notes.

The examples of commands are:
- Create account.
- Send e-mail.
- Sell tickets.
- Complete payment.

_Reactions_

The next step in the process is writing down what will happen as a result of previously defined events. They are put on green sticky notes in future or present tense.

Examples of the reactions are:
- Creating account results in sending a confirmation e-mail.
- Sending e-mail results in confirming the participation.
- Selling the results of the ticket in blocking the reservation system.
- Completing the payment results in sending an e-book.

Combining events, commands and reactions helps to map the processes and visualize the functionality of the system.

**5. Domain-driven design**

The next step of an Event Storming session is creating a domain-driven design. This part is optional but can help you to define the structure of the system and make further implementation easier and more smooth. In simple words, the previously created modules can be now grouped by using boxes, circles, and arrows that provide context for sticky notes. 

For example, you can group together the events and reactions related to automated messages sent by the e-mail marketing system, and then define how they are linked to digital advertising, payments, shipping options, etc. Thanks to this, all participants will be able to see how modules interact with each other, influence the flow of the process, and will be able to develop the full visual picture of the system’s functionality. 


As you can see, Event Storming is a simple but effective method that can accelerate teamwork, contribute to the product designing process, and bring significant value to the business domain.

At Amsterdam Standard, we use Event Storming and other creative methods on a daily basis while developing projects for our clients. If you feel like working in a creative, cooperative team utilizing modern, interactive methods, feel free to check out our open positions and send your CV.

Event Storming: what it is, benefits & risks

What values Lean management can bring to project and team management? Let’s take a look at this together.

#### What values Lean management can bring to project and team management? Let’s take a look at this together.


Lean management is mostly associated with manufacturing, but some parts of its philosophy can be successfully applied to project management and even team management.

Let’s start with Kaizen, a continuous improvement methodology that originated in the Japanese manufacturing industry. Kaizen principles can be well applied in other industries. I’d like to present to you the fundamentals of it and illustrate how we can use them in project management.

Maasaki Imai, who introduced the Kaizen approach described the whole concept in one accurate sentence: “Kaizen is everyday improvement, everybody improvement, everywhere improvement.” The word Kaizen stands for “Good” (zen) and “Change” (kai). 

The core of Kaizen’s philosophy are 10 principles that allow you to understand the whole mindset:
1. Let go of assumptions.
2. Be proactive about solving problems.
3. Don't accept the status quo.
4. Let go of perfectionism and take an attitude of iterative, adaptive change.
5. Look for solutions as you find mistakes.
6. Create an environment in which everyone feels empowered to contribute.
7. Don't accept the obvious issue; instead, ask "why" five times to get to the root cause.
8. Collect information and opinions from multiple people.
9. Use creativity to find low-cost, small improvements.
10. Never stop improving.

Teams that are already working in Scrum, might even not know that they’re already using camouflaged Kaizen’s technique: PDCA - plan, do, check, act.

- **Plan** - it’s nothing else than planning a Sprint and all the work that needs to be done
- **Do** - Ongoing Sprint while we’re delivering the work
- **Check** - demo and retrospective (what else is a retrospective meeting than seeking improvement?)
- **Act** - all the action items taken to improve the process, team collaboration, and delivered product

We can say that Kaizen gave birth to the idea of continuous improvement in Agile.

Taking a look at retrospective meetings, it’s team time to think about what went well, what could be better, and what improvements can be made, so it’s a powerful tool that allows the team to continuous improvement, therefore practicing Kaizen. They can identify small steps, be proactive about solving problems and make changes in an iterative way. 

From a project management perspective, a very useful technique might be asking 5 times why. Cast the first stone who was not struggling with the issue, racking his head about the root cause. So, when the problem occurs you can drill down in a simple way, to peel off the symptoms layers, discover ‘the truth’ and prevent issues from recurring. 


If Kaizen is about continuous improvement, we could also use it just for people. Companies, projects, and processes… but the heart of all of it are people. What’s the best way of using Kaizen for individuals? It’s a feedback loop. 
Asking for feedback or giving feedback is not a simple thing, but we all know it’s needed for both improvement and growth. Using the Kaizen philosophy in team management could be feedback based. 
First, we should focus on continuity. Giving feedback once won’t change much, improvement will take place if we will make it with a specific frequency, on a continuous basis. What’s also important is that it should be goal-oriented, not time oriented, and perfectly divided into smaller objectives. As Kaizen says: Let go of perfectionism and take an attitude of iterative, adaptive change. It also means that by giving feedback we should be as specific as possible to give improvement opportunities as soon as possible (in an interactive way). 
Good feedback also doesn’t give ready solutions. Empower people to actively seek improvements and growth opportunities, solving issues and being proactive about that. A perfect way to talk about feedback and shortcut the distance between the leader and team member is Gemba's walk.


Gemba is a Japanese word that means 'the real place', but lean management adopted it to describe any location where work happens. The most important aspect of Gemba is the “Gemba walk” which is literally a walk and it encourages leaders/managers to interact with people they work with, and interact with projects and processes. 
Why is it important? It gives both leaders and managers a better overview of the project and could help to obtain more details, and understand the team as a whole and all the members. 
What will it give you? More transparency and trust encourage greater communication which is a perfect ground for building strong, well-performing teams. 


Don’t forget to improve!

Amsterdam Standard officially announced the acquisition of the leading Laravel development company HighSolutions from Poznan. 


Amsterdam Standard officially announced the acquisition of the leading Laravel development company HighSolutions from Poznan. Together, they will grow their footprint over Poland and continue delivering team augmentation services for fast-growing SaaS companies in the Netherlands. The HighSolutions team will be fully integrated into Amsterdam Standard, and both companies will continue under the brand of Amsterdam Standard. 

In a labor market where development talent is scarce, Amsterdam Standard has been delivering top-notch development power for almost 19 years. Employing ± 170 experts - spread over five offices in Poland and Amsterdam - both companies combine the power and flexibility of remote development teams with the advantages of local project management, UX/UI design and quality assurance.

Currently, the company delivers development teams for more than 40 innovative Dutch clients, such as MrWork, ChannelEngine, Nutricia, Orderchamp, LeadingCourses, Yesty, WPP, GoBoony, Tiqets and many more.
 
The founders of HighSolutions have acquired a stake in the holding company of Amsterdam Standard (Saasmore) and have already joined the management team of Amsterdam Standard.
The daily management of Amsterdam Standard is still in the hands of current Amsterdam Standard CEO Tomasz Rzany. In the next three years, the company will aim to double in size by expanding in Poland.


>"From the beginning, I knew that Amsterdam Standard was the right partner for us to join forces,"

explains Adam Matysiak, co-founder of HighSolutions. 


>"We were ready to take the next step. Thanks to a stronger operations team, more mature processes and a more efficient business model, we can deliver more value than before. The knowledge, experience, and team of Amsterdam Standard are just top-notch, and we will highly benefit from their culture. Moreover, their mostly Dutch clients will bring interesting new opportunities for our current developers. And I believe that we will also deliver outstanding results to Amsterdam Standard and their clients." 

Adam Machowiak, the second co-founder continues: 

>“We are pretty sure that we can double our team in Poznan now quickly to ± 60 colleagues. To accommodate that growth, we will move into a new office soon, and we are very excited about that!”


>"With HighSolutions, we onboard tons of experience to our team that will help us with our growth in Poland and the Netherlands,” 

says Tomasz Rzany. 


>“They built a very well-recognised Laravel specialized boutique agency with great clients. This deal will strengthen our position as a leader in team augmentation for SaaS businesses, and their access to high-end development talent in Poznan will help us achieve our clients' ambitions even better. In 2021 we experienced such a big demand from our existing clients that we rapidly needed to scale up our operations to stay a relevant partner for them. We always wanted to build a presence in Poznan since this city hosts an amazing eco-system for tech companies. The conditions and infrastructure are just perfect there. I am delighted that the team of HighSolutions will now join our ranks to help us achieve our mission."

Would you like to know more about this acquisition? Please contact Tomasz Rzany (tomasz@amsterdamstandard.com) or Adam Matysiak (adam@amsterdamstandard.com).


HighSolutions joins forces with Amsterdam Standard

1563268297_white-paper-a-tight-labor-market-in-dutch-ict.pdf

Dutch economy and the role of the ICT sector in it

An alternative solution for ICT specialists recruitment

Geographical areas of recruitment tension

WHITEPAPER

A tight labour market in Dutch ICT

The influence of the pandemic on the ICT market

How can your company adapt to the new reality

Stories

Our thoughts and ideas

Top 6 things that demotivate a developer

Project Management - best practices

Event Storming: what it is, benefits & risks

Don’t forget to improve!

HighSolutions joins forces with Amsterdam Standard

WHITEPAPER

A tight labour market in Dutch ICT

WHITEPAPER

Nearshoring in (post) COVID-19 times