<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Because Tech Rocks</title>
    <link>/</link>
    <description>Recent content on Because Tech Rocks</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Sun, 19 Jun 2022 00:00:00 +0000</lastBuildDate>
    
	<atom:link href="/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>Outcomes over outputs</title>
      <link>/blog/outcomes/</link>
      <pubDate>Sun, 19 Jun 2022 00:00:00 +0000</pubDate>
      
      <guid>/blog/outcomes/</guid>
      <description>The concept of using outcomes over output has caught my attention pretty early on in my career - as it’s such an obvious and seemingly easy concept, yet still hard to implement properly. And at times it produces somewhat challenging situations when working with people who are used to working in a more “command and control” like environment.
The book The book I summarize here today is a short one titled “Outcomes over Output”.</description>
    </item>
    
    <item>
      <title>Rethinking bounded contexts</title>
      <link>/blog/bounded-contexts/</link>
      <pubDate>Thu, 06 May 2021 00:00:00 +0000</pubDate>
      
      <guid>/blog/bounded-contexts/</guid>
      <description>I was wrestling quite a bit with my colleagues recently about how we could benefit from DDD, especially from the notion of bounded contexts. We somehow felt that the concept is an important building block for how we split up our services, but we had some trouble to really make the DDD ideas work in practice.
Right in time, I stumbled across a video by Nick Tune which I found very useful (full video is linked at the end of the post).</description>
    </item>
    
    <item>
      <title>The Effective Engineer</title>
      <link>/blog/the-effective-engineer/</link>
      <pubDate>Mon, 05 Apr 2021 00:00:00 +0000</pubDate>
      
      <guid>/blog/the-effective-engineer/</guid>
      <description>&amp;ldquo;Time is our most finite asset, and leverage &amp;ndash; the value we produce per unit of time &amp;ndash; allows us to direct our time toward what matters most&amp;rdquo;. This is one of the core ideas of the book &amp;ldquo;The Effective Engineer&amp;rdquo; by Edmund Lau.
Now, doesn&amp;rsquo;t that sound a lot like Andy Grove in his &amp;ldquo;High Output Management&amp;rdquo; book? Indeed, it does, and the book makes a couple of references to Grove.</description>
    </item>
    
    <item>
      <title>Product Roadmaps done right</title>
      <link>/blog/roadmaps-mccarthy/</link>
      <pubDate>Mon, 25 Jan 2021 00:00:00 +0000</pubDate>
      
      <guid>/blog/roadmaps-mccarthy/</guid>
      <description>I have been frustrated with creating roadmaps for a long time &amp;ndash; until I met Bruce McCarthy at a workshop. I stumbled across a great video of his that gives a pretty nice summary of his roadmapping approach.
I&amp;rsquo;ll eventually summarize my take-aways, but for I can just recommend to watch the video:
  </description>
    </item>
    
    <item>
      <title>Andy Grove&#39;s High Output Management</title>
      <link>/blog/high-output-management/</link>
      <pubDate>Sun, 03 Jan 2021 00:00:00 +0000</pubDate>
      
      <guid>/blog/high-output-management/</guid>
      <description>I finally managed to pick up some long standing items from my reading list over the holidays. Here&amp;rsquo;s a few notes from Andy Grove&amp;rsquo;s &amp;ldquo;High Output Management&amp;rdquo;. My expectations were set pretty high as the book was advertised by several people to me as the ultimate management bible. However, I have to admit that I was not completely blown away &amp;ndash; maybe that&amp;rsquo;s a good sign though, as many of the key concepts probably have just made it into common management wisdom.</description>
    </item>
    
    <item>
      <title>A Philosophy of Software Design</title>
      <link>/blog/design-philosophy/</link>
      <pubDate>Fri, 04 Dec 2020 00:00:00 +0000</pubDate>
      
      <guid>/blog/design-philosophy/</guid>
      <description>A colleague of mine pointed me to a book called &amp;ldquo;A Philosophy of Software Design&amp;rdquo; by John Ousterhout. It tackles a very interesting point: students of software engineering (and less so self-educated programmers) often times learn a lot about object orientation, algorithms and all kinds of funky theory, but there is very little time spent on practical software design. The preface of the book also raises the thought that this mystical difference in productivity between the best programmers and an average programmer is less likely just rooted in talent, but rather to high-quality practice than can be taught and learnt.</description>
    </item>
    
    <item>
      <title>My notes on &#39;Monolith to Microservices&#39;</title>
      <link>/blog/building-microservices/</link>
      <pubDate>Mon, 05 Oct 2020 00:00:00 +0000</pubDate>
      
      <guid>/blog/building-microservices/</guid>
      <description>I got Sam Newman&amp;rsquo;s new book &amp;lsquo;Monolith to Microservices&amp;rsquo; in my handy and scribbled down a few notes that I found worth extracting. This is by no means a full book summary - which indeed is difficult to a book that already is a summary on the topic.
Handy definitions I like Sam&amp;rsquo;s microservice definition: &amp;ldquo;Microservices are independently deployable services modeled around a business domain. The desire for loosely coupled services with stable interfaces guides our thinking about how we find service boundaries in the first place.</description>
    </item>
    
    <item>
      <title>How we built EGYM</title>
      <link>/blog/podcast-cleevio/</link>
      <pubDate>Wed, 19 Aug 2020 00:00:00 +0000</pubDate>
      
      <guid>/blog/podcast-cleevio/</guid>
      <description>Jan Kartusek was so kind to invite me to his Podcast series to speak a bit how we built EGYM and how the engineering organization at EGYM is set up.
Here&amp;rsquo;s the link to the full article [https://www.cleevio.com/blog/25-florian-sauter---how-he-built-a-global-fitness-technology-leader-egym]
 </description>
    </item>
    
    <item>
      <title>Key points from Accelerate</title>
      <link>/blog/accelerate/</link>
      <pubDate>Sat, 21 Dec 2019 00:00:00 +0000</pubDate>
      
      <guid>/blog/accelerate/</guid>
      <description>I recently read Accelerate by Nicole Forsgren, Jez Humble and Gene Kim. This is not a classical book summary, but rather a collection of thoughts from the book which I found worth noting down. I have to say upfront: I really love the book’s approach of only presenting results that have a measurable proof - which sets it apart nicely from all kinds of heavily opinionated literature on software development and delivery.</description>
    </item>
    
    <item>
      <title>Nine lies about work</title>
      <link>/blog/nine-lies-about-work/</link>
      <pubDate>Sat, 28 Sep 2019 00:00:00 +0000</pubDate>
      
      <guid>/blog/nine-lies-about-work/</guid>
      <description>Recently I read “Nine lies about work - A freethinking leader’s guide to the real world” by Marcus Buckingham and Ashley Goodall. The book’s provoking title caught my attention. I was not disappointed, although I have to admit that the book occurred a bit lengthy to me at times. Let me share some of my take-aways in this summary.
People care about their experiences in a team, not the company they work for The first of the “nine lies” reads “People care which company they work for.</description>
    </item>
    
    <item>
      <title>Misunderstandings in innovation cultures</title>
      <link>/blog/innovation-cultures/</link>
      <pubDate>Sun, 09 Jun 2019 00:00:00 +0000</pubDate>
      
      <guid>/blog/innovation-cultures/</guid>
      <description>Last year I did a review of Marty Cagan’s “Inspired” book. The book provided a characterization of innovation cultures and how the best product companies in the world differ from the rest. He characterized innovation cultures as open minded, with a high willingness to experiment, empowerment and business- and customer-savy teams. These all are very easy to like characteristics, yet they seem to be really hard to implement in a way that really yields great results.</description>
    </item>
    
    <item>
      <title>Myths about AI</title>
      <link>/blog/evans-on-ai/</link>
      <pubDate>Thu, 06 Dec 2018 00:00:00 +0000</pubDate>
      
      <guid>/blog/evans-on-ai/</guid>
      <description>What comes into your mind when thinking about artificial intelligence and machine learning? Assosiations of flying saucers? Or Google, Facebook and China ruling the world with their (evil?) empires of data? Or the conversations with family and friends that have read in the newspaper that AI will now take over and replace all of our jobs?
These are all common things you stumble upon in Ai discussions, but none of them are very helpful to understand the essence of what machine learning today really is and how it can help us.</description>
    </item>
    
    <item>
      <title>Inside Apple&#39;s design process</title>
      <link>/blog/inside-apple/</link>
      <pubDate>Wed, 31 Oct 2018 00:00:00 +0000</pubDate>
      
      <guid>/blog/inside-apple/</guid>
      <description>I stumbled upon this book written by Ken Kocienda recently. And it seemed like a great chance to understand a bit more about Apple&amp;rsquo;s secret sauce, especially as Apple is notoriously secretive abouts its internals. So I decided to buy the book (despite the fact that the paperback version has one of the ugliest book covers in history - which is kind of funny as one would expect exactly the opposite from something that talks about Apple).</description>
    </item>
    
    <item>
      <title>Book Summary: How to fly a horse</title>
      <link>/blog/how-to-fly-a-horse/</link>
      <pubDate>Sat, 19 May 2018 00:00:00 +0000</pubDate>
      
      <guid>/blog/how-to-fly-a-horse/</guid>
      <description>The book and why you should read it Before diving into the content of this book, let me tell you one thing: This is one of the rare books that I would recommend anyone to read at full length, just because it&amp;rsquo;s so well written and contains so many nice anectodes that it is impossible to get across the whole message in a summary. So make sure to get you own copy at Amazon.</description>
    </item>
    
    <item>
      <title>Removing poetry from innovation</title>
      <link>/blog/innovation/</link>
      <pubDate>Tue, 10 Apr 2018 00:00:00 +0000</pubDate>
      
      <guid>/blog/innovation/</guid>
      <description>I had the chance to meet Bill O&amp;rsquo;Connor in San Francisco recently. He did a highly inspiratinoal talk about Innovation (of which you can find an a bit less inspiring version also on YouTube).
What is innovation? So Bill&amp;rsquo;s talk was all about innovation. But what is innovation really? He comes up with the following definition:
 Innovation is &amp;ldquo;something new or different, successfully brought into the world, creating significant impact&amp;rdquo;</description>
    </item>
    
    <item>
      <title>Book Summary: Inspired</title>
      <link>/blog/inspired/</link>
      <pubDate>Tue, 06 Mar 2018 00:00:00 +0000</pubDate>
      
      <guid>/blog/inspired/</guid>
      <description>Introduction The tagline of this book by Marty Cagan sounds ambitious: &amp;ldquo;How to create tech products customers love&amp;rdquo;. Marty Cagan brings a lot of credibility as an author as he has worked with some of the early pioneers of our industry (Hewlett-Packard, Netscape, eBay) and now heads the Silicon Valley Product Group and is considered to be one of the thought-leaders of technology product management.
Structure of the book (and the review) The book is divided in five major parts:</description>
    </item>
    
    <item>
      <title>Book Summary: Lean Enterprise</title>
      <link>/blog/lean-enterprise/</link>
      <pubDate>Sun, 11 Feb 2018 00:00:00 +0000</pubDate>
      
      <guid>/blog/lean-enterprise/</guid>
      <description>Introduction I read the book &amp;ldquo;Lean Enterprise - How high performance organizations innovate at scale&amp;rdquo; by Jez Humble, Joanne Molesky and Barry O&amp;rsquo;Reilly a while ago in its 2016 edition. After coming back to the book about 2 years later and still thinking the content is hugely relevant, I thought it might be a good idea to summarize the main ideas and present you some of the quotes I consider relevant, exciting or especially controversial.</description>
    </item>
    
  </channel>
</rss>