Hi, we are AppUnite, we take care of the businesses from a tech perspective. We build products and teams around them enabling our clients to bring the difference to the world.

We believe in knowledge sharing and software as a tool to improve companies and peoples’ lives. We take lessons from our daily challenges and share that experience and knowledge to help you build better products. 

Let’s talk about products, businesses, and software development!

Usually, we think about the code and artefacts connected with it (like documentation, releases, pipelines) as an individual entity. A subtle connection between code and people isn’t apparent at the first glance and can be easily overlooked. Meanwhile, we should perceive those two things which constitute a digital product as a single bio-technological organism. Why is it valuable to think in that way? Why don’t we deliberate about such subtleties when we look at material products like a rake or a mug?

That’s due to one crucial attribute of software products - the ability to be shaped in another way. This adaptability opens a wide array of new possibilities and often it is a decisive point in winning or losing a market. We usually take it for granted that code can be reprogrammed, but actually keeping that perspective available is an ongoing endeavour and definitely, it’s not free. We can be perfectly ok with a rake which can’t adapt to the seasons, but having a digital product which has a fixed-forever set of features is unacceptable these days. This issue is often encountered in the post-MVP phase (you can read about it [here](https://appunite.com/blog/scaling-a-startup-post-mvp-challanges-we-have-launched-an-mvp-and-now-what)) and next to [technical debt](https://appunite.com/blog/what-is-technical-debt-and-how-to-manage-it) is a common challenge that needs to be faced. 
 
### What actually coding is

So what’s the connection between that adaptability and the human perspective? At the end of the day, a product is modified by people. Visual changes in the code or the design, are only materialized artefacts of internalized models. In order to change something, one needs to “decode” a model from code, internalize it, understand it, and then think about how it can be tweaked to support new requirements, and finally “encode” it back.

![Screenshot 2022-05-10 at 08.05.10.png](https://strapi-appunite.s3.eu-central-1.amazonaws.com/Screenshot_2022_05_10_at_08_05_10_7786db821d.png)

Nevertheless, humans are not computers. We have some limits within which we operate. Those limits are often described as **cognitive load**. And we can apply that term to the size of models with which we can operate efficiently, but also in terms of the number of personal relationships which we can keep healthy.

That leads us to the term called **Dunbar’s number**. It indicates how many relationships one can preserve. That number varies depending on the proximity of those relationships, but the most interesting for us is the number 15, which constitutes the *Circle of deep trust*. Why is it so important? Because it indicates to us the optimal size of a typical product team - which is usually around 8-10 people. The team states a peer-to-peer network, adding more and more “nodes” to it, makes things really hard.

![Screenshot 2022-05-10 at 08.05.54.png](https://strapi-appunite.s3.eu-central-1.amazonaws.com/Screenshot_2022_05_10_at_08_05_54_1ace68b18a.png)

That’s why it is really crucial to pay attention to the signs of that communication overload. There is a natural equilibrium point beyond which, increasing team structure size exposes us heavily to **the law of diminishing returns**. In most cases making 10+ people teams is impractical and should be avoided. Generally, the smaller team is, the less we suffer from communication problems.

![Screenshot 2022-05-10 at 08.06.27.png](https://strapi-appunite.s3.eu-central-1.amazonaws.com/Screenshot_2022_05_10_at_08_06_27_7bf655b185.png)

But it’s really hard to imagine those huge and ambitious products are supported by only 10 people. And that leads us to...

### Divide and conquer

Probably, when you were reading the previous paragraph, you came to the natural conclusion about team structure - “We should then create two smaller teams instead of one big”. As we have hard constraints on human mental capacity, then we probably should move a slider with the label “number of teams”.

![Screenshot 2022-05-10 at 08.06.55.png](https://strapi-appunite.s3.eu-central-1.amazonaws.com/Screenshot_2022_05_10_at_08_06_55_e76d3afa87.png)

It is one of those things about team topologies, which are simple but not easy. Facing that process implies several ramifications. The first scope of work needs to be divided somehow. If we hope to allow teams to achieve their full potential, we should aim to maximise their autonomy. That’s one of the tenets defining an agile team, it should be capable of delivering a stream of value independently through the whole stack. From discovery, design, development, and testing to maintaining it on the production. Being constantly blocked by the members of other teams violates the autonomy principle, cripples development and is devastating for the team morale.

There is another really interesting hue of dividing the work. It is associated with that internalised way of modelling code mentioned earlier in the article. Really often **Conway’s Law** comes into play. It says that *organizations design systems that mirror their own communication structure*. So we can conclude that, if previously there was only one team which was working on some system, they created an architecture optimized for the way they work.

![Screenshot 2022-05-10 at 08.07.20.png](https://strapi-appunite.s3.eu-central-1.amazonaws.com/Screenshot_2022_05_10_at_08_07_20_a7d1756fd1.png)

The fact that we decided to split a bigger team into 2 smaller ones, doesn’t automatically split our product into sub-products nor the underlying code or the architecture. And that can be problematic, because instead of being “enabled” folks in those teams will be struggling with the ecosystem. At first, their productivity will suffer from the team reconstitution process - after each change of team member, the team needs some time to “regel”. But moreover, changing team topologies has changed communications patterns. It’s a very important thing to remember when comes to team topologies - they need some space to adjust the reality with which they cope everyday, to those new patterns. 

But in the simpler words. If previously, they were working on a big monolithic application with collective ownership, they need to decide if they want to keep an architecture that way and just create a “softer” internal boundaries of ownership, with a joint release cycle. Or maybe the architectural drivers for those 2 parts of the product are incompatible to such an extent that it is beneficial to introduce a hard split, and spawning fully independent service.

I hope this article gave you some clue about what team topologies are and what are the most common obstacles when comes to creating team structures. Generally speaking, it’s heavily context dependent, and basically, throughout the above paragraphs, we were raising the sentence “it depends” to the power of infinity.




large_michael-myers-XzAUWNPCp1A-unsplash.jpg

medium_michael-myers-XzAUWNPCp1A-unsplash.jpg

small_michael-myers-XzAUWNPCp1A-unsplash.jpg

thumbnail_michael-myers-XzAUWNPCp1A-unsplash.jpg

michael-myers-XzAUWNPCp1A-unsplash.jpg

If you are in post-MVP phase you need to optimize your team size. Read this article to find out how team topologies change communications patterns. 

Team topologies - optimizing software team size

I remember that phone call very well. In fact, it might be one of the most memorable phone calls I have ever picked up or even one of the most important calls in my life. You know, one of those phone calls that give you a mini heart attack when you look at the screen and see a familiar phone number.

*Mr. Kuleczka?*

*Hello, yes.*

*Good news - **you’ve just got a job at AppUnite**. When can you start?*

It was a warm, yet cloudy October day. I picked up the call while having a break between some Math classes at my university campus, holding a cup of overpriced, bad coffee from a machine downstairs. I just left some company after 3-months of being a junior developer, which, in fact, felt more like an internship - not at my will, but because the company was going bankrupt. A charm of small startups, I guess. I was not that concerned about it, I thought that it might be a good start, a three months adventure that would eventually lead me to become a real developer, solving real-life problems. Problems that I solved in that company were not so challenging - we worked on an internal application, whose purpose was to be a showcase app to potential customers. My plan was to focus on my education and get back to the industry with some proven experience in the following year.

I felt joy, thrill, confusion and dread at the same time. *Wow, they want me! I’m gonna be a real developer! What if I’m not good enough? What if I am not able to solve trivial problems that I will encounter and I will be considered a failed investment? Maybe I’m not ready yet?*

All those thoughts clouded my mind as I started my first day at work, the beginning of an unforgettable journey. The first project I was assigned to was a logistic project, whose goal was to solve the problem of finding contractors to transport goods from point A to B.  At first, it was quite hard for me to handle the complexity of the project. Doubts kicked in again. What if I was not good enough?

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

**I received huge support from my teammates** - especially from my mentor, MK. (who I had kind of admired even before I started to work in AppUnite, as he was a pretty known persona in Elixir community and gave many interesting talks in tech conferences before) and my buddy, P. - and they guided me through the basics of development, showed me how the process looked and what to do to be able to solve complex problems in an efficient way. We spent many hours drawing diagrams on whiteboards, trying to illustrate our thoughts and ideas. My role in the project was not that vital, however, I felt I was helping the team and bringing value to the table from the beginning. It is a great merit of my colleagues, who made sure that I felt comfortable and knew what I was supposed to do and also gave me great feedback regarding my work. They always treated me equally despite my young age and lack of experience. Anxiety slowly creeped out of my mind as I was slowly making meaningful progress and being praised by my teammates. I enthusiastically observed how quickly the number of comments to my pull requests was reduced, indicating the growing trust of the people that I worked with. **Truly unforgettable feeling**, when you feel this ‘click’ in your head and you become a useful team member, delivering quality production code in a reasonable time.

However, it was just the first episode of the story. I was assigned to this project to learn the basics, but the long-term plan was to engage me in the development of some other product. After three months, it was time to leave. I felt sad, as I worked with truly amazing people and it was a shame to leave them, but also excited about the new opportunity - I felt as if that was where the true challenge would begin. I was surprised by how warm my team members were to me, saying goodbye and wishing me the best of luck. It was a cold Friday at the beginning of January. At the end of my workday, I gave my last high-fives to my now-ex-teammates and went home to unwind through the weekend and prepare for a new project.

*It was a pleasure to work with you, guys. Thanks for your knowledge and everything.*

*It was indeed, Szymon. You're gonna learn a lot about the new product.*

I was moved to one of the biggest teams in the company, working on one of the first products that AppUnite had ever launched - a social media app, dedicated to the Christian community in Africa. Sounds quite unusual? Yes, that is what I felt, but in the end, it was a really interesting experience. The user base was quite big, as there were approximately 160k active users. **In AppUnite, we aim to have a huge impact not only on the technical stuff, but also on product development and business**, and this project was one of the finest examples as our client often was not only focused on their ideas but gave us a freedom to propose our own features and ideas to improve the product and user experience. To do so, you need to know your user base - it was really interesting to observe content posted by users from completely different cultures than I was raised.

*Are you Szymon? *- asked K., my new buddy.

The whole team was working on a completely different floor, so the environment was quite new for me. I didn’t know anyone, which made me feel uncomfortable in some way, however, K’s friendly, a little bit goofy approach, quickly loosened me up as he introduced me to other team members and helped me to set up the project, showed me where to look for documentation and gave other useful advice.
Everything was going well during the initialization, however, I was terrified again soon, when I started to explore a brand new codebase.
It was far, far more complicated than the previous one. The lines of code seemed to be infinite, conventions were completely new and unfamiliar to me. I felt completely the same as in the beginning - a little bit lost and doubtful. I was just scrolling through the countless modules brainlessly, thinking that there was no way I could handle that. 

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

Things started to get worse when I got my first task. I had to refactor the old, legacy code, which was using the database that our backend team wanted to get rid of. The problem seemed quite simple in the beginning, but later, partly because of my lack of skills, knowledge and experience, which would help me to organise work in a way that would be much easier for me, it occurred to me that the task was much harder than I had thought. I spent days and days of this cold January in the office, getting warmed by a hot coffee and working on the first tough maintenance problem.
**However, I never felt alone**. Whenever I had an issue with some particular step, K. was always there for me and advised me without any sort of judgment.

*Look, try to draw what happens and when. It will help you, trust me* - K. encouraged me, reminding me of what we had done in the previous project.

And it worked. Things were much clearer when I simply sat and breathed for a second, trying to think of the solution and existing circumstances instead of starting coding immediately. The funny thing is that I received this lesson not only before, but also many times after this situation before I ultimately realized how I should approach problems. A trait of junior developers, or my trait, I guess.
After a couple of weeks, I finally got my first task done. Great! I was going to deploy my code to production in the new project for the first time! As usually in this job, I was both excited and nervous. I didn’t really know if things would go south or not. **Fortunately, I had the support of my colleagues, which ensured that they would help me in case something bad happened.**

*You ready, Szymon?*
*Yeah, kind of.*
*Don’t worry, it’s gonna be fine! You are not gonna break the production, for sure* - K. chuckled.

So I made the deployment.
Waited…
Nice, everything seems to be fine! The deployment was finished, and all servers were up and running. We were home!
I went to the kitchen to make some coffee with a smile on my face. I did a really hard job, I deserved a break.
After about half an hour after deployment, the client texted us in our shared Slack channel. Something was wrong, reaction counters in the posts showed 0 for everything!...
My face turned white and my stomach felt weird. *Is that possible that I did something pretty much irreversible? No, it is impossible that I broke it up so hard! How is it even possible it doesn’t work after all the tests that I had written were successful?!*
I sat in front of the computer and immediately started to look for reasons. *Why did it happen? It’s impossible! Why, why, why? Wait, I think I got it!*
It turned out to be a really specific case, which I am not going to explain in detail. However, I managed to perform a live migration in the production and restore all counters. Phew, I will not lose my job today!
**That was my next lesson, and from the time perspective, one of the most valuable ones**. Always remember that tests are based on your assumptions and the fact that they turned out to be successful is only a hint, you should not take for granted that the system will behave correctly. But what was probably more important, I realized that it makes no sense to deploy a lot of changes in the code at once. K. explained that to me, but either I didn’t listen, or I was not skilled enough to be able to properly divide my work. Anyway, this situation, the stress that I felt and the satisfaction of solving the issue were the emotions that I don’t think I will ever forget, nor the conclusions that I drew from this situation.

*Great work, bro, it’s really nice that you managed to fix your mistake. We are not gonna fire you today *- K. chuckled and patted me on the back in a gesture of encouragement.

![177A2225-3.jpg](https://strapi-appunite.s3.eu-central-1.amazonaws.com/177_A2225_3_1f19f3c79c.jpg)

That is one of the things that I liked the most about my then-current team, the previous team, and, as I quickly realized, the whole company. Everyone was so professional, yet so chilled at the same time. I messed up, but I quickly came up with a solution. All of my colleagues were super helpful and understanding. They did not underestimate the fact that I broke functionality in the prod, however, they were able to joke about it (even a long time after it happened…) and they were not bringing me down or yelling at me. **Atmosphere, atmosphere, atmosphere - one of the key things that I love at AppUnite.**



Joshua Myklusz

Best practises of knowledge sharing in the workplace