(Engineering) Management

• Development Cadence
  One of the foundational challenges of scaling a startup is crafting an efficient development engine across product, engineering, and design that maximizes throughput of product innovation with as little thrash, burnout, or stagnation as possible. The hallmark of a well-run development engine is a development cadence that is brisk in bringing new products to market without burning out its builders. Developing a “brisk but not burning” development cadence is one of the most high value things a startup can do, if not the single best way to align teams around a strategy, build and fortify a market position, and create an enduring company. A company that has a healthy development cadence ships regularly. This might seem obvious, but aspirational market leaders in tech like Apple are able to get away with launching just a couple of times a year. Startups don’t enjoy the same luxury — a startup’s single biggest structural advantage over incumbents is speed. Even companies that ship to production every day can benefit from packaging releases internally into product “launches” to further internalize a consistent launch tempo. Establishing a practice of showing and sharing work helps ensure accountability, builds momentum and enthusiasm, and brings a roadmap to life for internal collaborators and stakeholders. Each feature should have a “Directly Responsible Individual.” This person could be in any function but is typically an engineer, PM, or designer. They are the internal stakeholder for all questions, concerns, and ensuring that development is on the rails. While I’m a big believer in small, highly collaborative development teams, having a single point of contact ensures internal clarity of roles and expectations. Development cadence is ultimately the pulse of any startup. Establishing a brisk but not burning one early is critical, and finding ways to measure yours over time ensures ongoing velocity.
• Why perfection is the enemy of done
  I came across quite a few conversations about if we’re ready to launch, if we should not think about those edge cases, if it isn’t too small to communicate about etc. A lot of ‘Ifs” that all block us from progress and momentum. Especially in startups and tech organizations, we need to make sure to always follow the Agile principle of creating value as soon as possible. That’s why we launch MVPs, have continuous delivery, and keep planning and delivery cycles as short as 1 or 2 weeks. Even the biggest engineering initiatives should see daylight and add value frequently. This article summarizes the principle ‘Progress beats Perfection’ pretty well.
• What a Senior Staff Software Engineer actually does
  Quite interesting read: Based on the reality, that most company established a parallel career path besides management for individual contributors, it is still quite unclear what all these Staff and Principal Engineers actually do. In this article a Senior Staff Engineer from Box describes his role. “The easiest way to describe the role change as you move up is to say that the impact increases. This can be thought of in a couple of ways. Either you can have a broader impact or you can have a deeper impact. You can affect a lot of teams or you can very deeply affect one team. The author describes, he spends about 50% of his team within his actual team, the other half goes into responsibilities with broader impact: Design Reviews, Consulting, Mentoring, Tech Brand, API Council, Answering Questions, Larger Initiatives …
• Why is my team not doing what I expect from them
  Leaders who find themselves wondering why their teams aren’t making important decisions on their own tend to be leaders who are constantly pulled into many different discussions. Their calendars are filled to the brim, leaving little time for longer term work. This can seem like you’re contributing as a manager, like you’re doing important work and keeping yourself busy. It also means that you’ll have less time to focus on strategic work. Which becomes more important as you move into more senior roles. Not being able to scale yourself tends to go hand in hand with your team not meeting unwritten expectations. Inexperienced leaders tend to be hesitant setting expectations. Good expectations focus on context, frameworks, and outcomes. Teams can be blocked without clear expectations, but with good alignment expectations will help to grow leaders and scaling yourself. All of this is (the most important) leadership skill.
• A manager’s Bill of rights and responsibilities
  A nice list of things managers (should be) are responsible for and the rights they have.
• A theorem of Software Engineering
  About the “Shortest Possible Schedule” theory Steve McConnel published in 2006 about the question whether it makes sense to add staff to a project to shorten its delivery time. Everyone understands that if our project has been evaluated, through accepted cost estimation techniques, to require three developers over a year we cannot magically hire 36 people to complete it in one month. Productivity does not always scale up. But isn’t this also a management problem: Of course if you keep haplessly throwing people at deadlines you are just going to add communication problems and make things worse. But if you are a competent manager expanding the team size is one of the tools at your disposal to improve the state of a project, and it would be foolish to deprive yourself of it. Cost estimation is no longer a black art. It is not an exact science either, but techniques exist for producing solid estimates. Whatever you do, how many engineers you add, there is a firm limit to the time you can gain: 25%. It seems to be a kind of universal constant of software engineering.

Product Development

• Products are conversations
  We’ve lost our way in Product Management. When the biggest problem Product Managers face is setting roadmap priorities based on market feedback, it’s symptomatic of the underlying practices and tools. Simply put, Products are Conversations. How you orchestrate conversations with customers and cross-functionally in your organization is what makes great products. Agile was supposed to bring product creation closer to the customer. But there is too much distance, data, organizational complexity. Using data to drive product decisions is particularly great for finding things that don’t work. But usage data is just one factor for decision making, and because in PM meetings it’s something you can point to as evidence to support an argument, it’s often overweight (particularly when the presenter has good persuasion skills). The PM as the CEO of Product is dysfunctional myth. The PM may have the decision rights for product, but her stakeholders have decision rights for organizational functions, and their goals, objectives and resources may run counter. The clueful will recall that Markets are Conversations. Customers are empowered and authentic voice cuts through all the noise in today’s marketplace. Your customers want to talk with you, the PM. They want to be heard and want you to understand their needs. It’s your job not to let things get in the way of these conversations, and figure out how to have them at scale. Turn conversations into insight, Turn conversations into plans, Turn conversations into actions, Turn conversations into continuous improvement
• Mastering the art of the outcome: turn customer success into a company cornerstone
  I love the articles that are published on firstround.com. This one is another awesome piece of thought. “The ability to demonstrate value to customers can determine whether a startup generates a wave of sustainable success — or fades into irrelevance with the next tide.” Consequently, Guru’s approach to proving customer outcomes is meticulously quantified, rigorously unambiguous, and integrated into every facet of the company. In a recurring-revenue world, every year is an opportunity for a customer to question whether your service is actually adding value. The answer to that question better be yes — or your ship might sink faster than you can correct your course. “A lot of startups get attached to this quixotic goal of growing fast and selling a product to every vertical, to every business in the world,” he says. “But what most founders don’t anticipate is that you run into more problems the wider you cast your net.” When you’re building a product, don’t try to solve all the problems in the world. Focus on solving the most important problems extremely well. The article outlines a playbook for mastering the art of the outcome: 1. Define a focused, tangible language for success. 2. Zoom in on the metrics that matter. 3. Establish the one or two metrics that matter most. 4. Generate progress reports. Shine the limelight on outcome-boosting performers. Chronicle your company #wins. Structure your teams around outcomes. For startups, being rigorously outcome-oriented is a tremendous opportunity to differentiate yourself in a competitive market
• The day of a Product Manager in a Startup
  Maitri, a PM colleague of mine at Omio, wrote this interesting and fun-to-read article about her day to day work as a Product Manager. As how Product and Engineering Managers work together to form leadership teams for respective teams is one of the most crucial success criteria, I really recommend reading this article and also learn about Product Management in general. (Hint: Listening is key)
• A very simple way to think about OKRs VS KPIs
  OKRs are for ambition, KPIs for stability and health.

Personal Development

• Generalize, don’t specialize: Why focusing too narrowly is bad for us
  The 10,000-hour rule says intense, dedicated practice makes perfect — at that one thing. But what if breadth actually serves us better than depth? Scientists have found that, at a younger age, those who go on to become elite athletes typically devote less time to deliberate practice in the activity in which they will eventually become experts. Instead, they undergo what researchers call a “sampling period”. They play a variety of sports, usually in an unstructured or lightly structured environment; they gain a range of physical proficiencies from which they can draw; they learn about their own abilities and proclivities; and only later do they focus in on one area. The title of one study of athletes in individual sports proclaimed “late specialisation” as “the key to success”; another was titled Making It to the Top in Team Sports: Start Later, Intensify, and Be Determined. The challenge we all face is how to maintain the benefits of breadth, diverse experience, interdisciplinary thinking and delayed concentration in a world that increasingly incentivises or even demands hyperspecialisation. While it is true that there are areas that require individuals with Tiger’s precocity and clarity of purpose, as complexity increases — as technology spins the world into vaster webs of interconnected systems in which each individual only sees a small part — we also need more Rogers: people who start broad and embrace diverse experiences and perspectives while they progress. People with range.

Software Engineering

• How to write a kickass README
  Things can be so easy. This one describes how to really write a project README that actually adds value.
• 3 Kinds of Good Tech Debt
  “Tech debt” is a dirty word in the software engineering world. It’s often said with an air of regret; a past mistake that will eventually need to be atoned for with refactoring. Financial debt isn’t universally reviled in the same way. Your friend takes out a mortgage to buy a house and what do you say? Congratulations! Bonds are a standard form of financing for infrastructure and public works. Businesses use all kinds of debt, and Wall Street shows its confidence in the form of higher stock prices. The difference is intention. What if tech debt wasn’t always an accident, caused by incorrect assumptions and unexpected circumstances? How would you spend a tech debt mortgage? This article outlines 3 types of Tech Debt that are actually good!
• GRIT — a protocol for distributed transactions across microservices
  This article describes the basic ideas of the GRIT protocol, which was announced at the IEEE International Conference on Data Engineering (ICDE) 2019, and provides an example of using part of the protocol for implementing a transactional storage backend for JanusGraph. This example focuses on a system with only a single database, but as we said, GRIT can support ACID transactions for systems consisting of multiple databases.
• The holy grail of Web Scalability
  A simple yet pretty complete round up of everything you need to know about web scalability… Maybe not everything in detail, but it gives a good overview.
• Testing Microservices: Six Case Studies with a combination of testing techniques
  Providing a holistic testing approach often requires the implementation of several testing strategies. These must be chosen carefully to avoid duplication of effort or the addition of accidental complexity to the test suite. Architects, developers, and QA teams must work together to understand and specify the testing goals, context, and current constraints. An important consideration when testing microservices is how to manage the associated dependencies. Various techniques can be used to decouple dependencies, but they all have tradeoffs that development/QA teams must be aware of.

Big Tech & Innovation

• The AI Revolution: The road to Superintelligence (Part 2)
  One of my favorite (and also one of the longest) posts of Tim Urban (waitbutwhy.com). We are on the edge of change comparable to the rise of human life on Earth. Read this, when you want to know why the far future is coming soon and why we can’t imagine how big it actually is. Learn about Ray Kurzweil “Human history’s Law of Accelerating Returns”. Kurzweil suggests that the progress of the entire 20th century would have been achieved in only 20 years at the rate of advancement in the year 2000 — in other words, by 2000, the rate of progress was five times faster than the average rate of progress during the 20th century. He believes another 20th century’s worth of progress happened between 2000 and 2014 and that another 20th century’s worth of progress will happen by 2021, in only seven years. A couple decades later, he believes a 20th century’s worth of progress will happen multiple times in the same year, and even later, in less than one month. All in all, because of the Law of Accelerating Returns, Kurzweil believes that the 21st century will achieve 1,000 times the progress of the 20th century. 2050 might be so vastly different than today’s world that we would barely recognize it. You may live to be 150, or 250, or not die at all, … your instinct will be, “That’s stupid — if there’s one thing I know from history, it’s that everybody dies.” And yes, no one in the past has not died. But no one flew airplanes before airplanes were invented either. Oxford philosopher and leading AI thinker Nick Bostrom defines superintelligence as “an intellect that is much smarter than the best human brains in practically every field, including scientific creativity, general wisdom and social skills.” Artificial Superintelligence ranges from a computer that’s just a little smarter than a human to one that’s trillions of times smarter — across the board. ASI is the reason the topic of AI is such a spicy meatball and why the words “immortality” and “extinction” will both appear in this post multiple times. (…) What we do know is that humans’ utter dominance on this Earth suggests a clear rule: with intelligence comes power. Which means an ASI, when we create it, will be the most powerful being in the history of life on Earth, and all living things, including humans, will be entirely at its whim — and this might happen in the next few decades.(…)