diff --git a/report.md b/report.md
index d646886..455eb5f 100644
--- a/report.md
+++ b/report.md
@@ -283,7 +283,58 @@ Problematic: development of a benchmark framework
 
 # Illustrated analysis of acquired skills
 
-# Added value
+# Benefits of the internship
+
+## Contributions to the company
+
+The work I have accomplished during my internship has resulted in tools that can
+be used as the basis for extensive testing using production binaries during the
+iteration of the development process.
+
+From this work we can retain two main points for IMC:
+
+* An extensible framework to use for benchmarking the gateways, and measure
+their performance. Thanks to the ease of writing new scenarios, and the
+integration of running the benchmarks with the build system in use at IMC, and
+its Continuous Integration pipeline, it can easily be used to monitor the
+evolution of performance and watch for regressions. Further down the line, it
+can be integrated with the change point detection service that is being
+developed in house, to simply contact the relevant people when the system
+detects that a regression has happened: the offending change can be identified
+more easily that way. This is key to staying competitive, ensuring the latency
+of our systems remain as low as possible and do not creep upwards.
+
+* My work on compatibility testing, which is an important step in avoiding any
+surprising behaviour or downtime in production. Due to the long turn around time
+of upgrades in certain regions, and the cost of lost opportunity for any down
+time, minimizing the probability of any problem that could be experienced
+results directly in more profits being made.
+
+## Furthering my learning
+
+During my internship, I got to work on a large code base, interact with smart
+and knowledgeable colleagues, and tinker on what constitutes the basic bricks of
+IMC's production software (FIXME: phrasing).
+
+Working at IMC was my first experience with such a large code base, a dizzying
+amount of code. It is impossible to wrap you head around *everything* that is
+happening in a given program. Up until that point I had only encountered school
+projects, of relatively small size and whose behaviour could easily be
+understood. Dealing with problems by trying to understand everything that is
+happening in a program is a valid strategy for those. It is not, however, a
+scalable way of working on software, and I needed change my way of thinking
+about and dealing with the problems I encountered during my work. To cope with
+that, I learned how to better handle problems I encountered by trying to isolate
+the actual source of the problem, instead of trying to understand the whole
+system around it.
+
+Interacting with the team was a great help in that endeavour. Knowing who to ask
+questions to, and learning how to ask relevant questions are once again
+essential in achieving productivity in those circumstances. This is doubly so in
+times of remote-working, when turning around and asking your colleague a
+question is not so simple. I had trouble at first to actively use the internal
+messaging app to ask questions, and was encouraged to ask questions liberally
+instead of staying stuck on my own.
 
 # Conclusion