The Manager's Guide – #68
Weekly Summary Edition
Happy New Year, folks! Let’s make 2024 the best year ever!
A Skeptic’s Guide to Software Architecture Decisions
🧐 Articulating and testing assumptions helps teams make better decisions by gathering more accurate information.
🤔 Every requirement, including Quality Attribute Requirements (QARs), is essentially a hypothesis about value that should be explicitly tested through designed experiments.
🛠️ Selective implementation of critical application parts allows for assumption testing at minimal cost, avoiding full implementation of entire requirements.
💡 Making implicit architectural decisions explicit enhances decision-making in development teams through empirical data from sprints/iterations.
🌐 Skepticism in architecture is not disrespect but a respect for the complexity of delivering excellent outcomes in a chaotic world.
🚀 Skepticism, a form of philosophical doubt, acts as an architectural superpower, enabling architects to see through false assumptions.
👀 Skeptical software architecture involves exploratory design driven by QARs, not just functional requirements, and focuses on validating these through experiments.
🚧 Being skeptical about vague or over-inflated requirements prevents over-engineering and builds necessary capabilities.
🔄 Skepticism aids in breaking analysis paralysis in decision-making by promoting empirical testing of alternatives.
🧪 Practical skepticism involves identifying assumptions, asking for evidence, and instrumenting systems to test these assumptions effectively.
📚 Historical examples like the Titanic disaster illustrate the consequences of ignoring skepticism.
🌟 Effective skepticism requires tact and an organizational culture open to validating assertions regardless of their origin.
What I Wish Someone Had Told Me
By Sam Altman
Optimism, obsession, self-belief, raw horsepower and personal connections are how things get started.
Cohesive teams, the right combination of calmness and urgency, and unreasonable commitment are how things get finished. Long-term orientation is in short supply; try not to worry about what people think in the short term, which will get easier over time.
It is easier for a team to do a hard thing that really matters than to do an easy thing that doesn’t really matter; audacious ideas motivate people.
Incentives are superpowers; set them carefully.
Concentrate your resources on a small number of high-conviction bets; this is easy to say but evidently hard to do. You can delete more stuff than you think.
Communicate clearly and concisely.
Fight bullshit and bureaucracy every time you see it and get other people to fight it too. Do not let the org chart get in the way of people working productively together.
Outcomes are what count; don’t let good process excuse bad results.
Spend more time recruiting. Take risks on high-potential people with a fast rate of improvement. Look for evidence of getting stuff done in addition to intelligence.
Superstars are even more valuable than they seem, but you have to evaluate people on their net impact on the performance of the organization.
Fast iteration can make up for a lot; it’s usually ok to be wrong if you iterate quickly. Plans should be measured in decades, execution should be measured in weeks.
Don’t fight the business equivalent of the laws of physics.
Inspiration is perishable and life goes by fast. Inaction is a particularly insidious type of risk.
Scale often has surprising emergent properties.
Compounding exponentials are magic. In particular, you really want to build a business that gets a compounding advantage with scale.
Get back up and keep going.
Working with great people is one of the best parts of life.
Improving Productivity and Happiness for Software Development Teams
LinkedIn has open-sourced its Developer Productivity & Happiness Framework (DPH Framework), a comprehensive guide to enhance developer efficiency and satisfaction.
📊 The DPH Framework focuses on data-driven approaches, utilizing metrics and feedback systems to tailor support for software development teams.
🛠️ Over four years, LinkedIn developed this framework, including guidelines and best practices for data pipeline implementers.
🎯 The framework introduces "Goals, Signals, and Metrics" as a high-level philosophy for deciding what to measure in developer productivity.
👥 Developer Personas, part of the framework, categorizes developers by workflow, helping to tailor priorities and solutions for different groups.
🤝 Persona Champions, volunteers from the engineering team, play a key role in understanding and communicating developers' needs within the framework.
📈 The framework emphasizes the importance of distinguishing between data and insights, as well as the appropriate use of quantitative and qualitative data.
📐 Principles for effective metric design, avoiding common pitfalls, and understanding the limitations of certain metrics are included in the framework.
📋 LinkedIn provides practical examples of specific metrics implemented within their organization to illustrate the framework's application.
📚 The DPH Framework is open-source, inviting community contributions and improvements to advance the understanding of software developer needs across the industry.
How we work asynchronously
PostHog’s take on remote/async work.
🌐 Transparency is central to their success, with open access to company information like financials, roadmaps, and work discussions.
👑 Contextual understanding is emphasized, with short, intense synchronous meetings to clarify goals and responsibilities.
✍️ Writing in public is key for context in an asynchronous environment, with documentation in pull requests, issues, and Slack channels.
🔄 Reducing work in progress helps maintain autonomy and minimizes the need for synchronous communication.
📝 The Request for Comments (RFC) process replaces stakeholder meetings, streamlining decision-making and feedback.
🚀 Async work benefits include more time for tasks, remote hiring flexibility, trust-building transparency, and clearer written communication.
⚖️ To mitigate downsides, PostHog balances async with regular sync-ups like standups, one-on-ones, and offsites.
🛠️ For an effective asynchronous toolkit, they suggest transparency, public roadmaps, RFCs, and a comprehensive use of GitHub.
Advice for new software devs who've read all those other advice essays
💡 Be skeptical but open-minded about advice and "objective truths" in software development.
📘 Read "Debugging: The 9 Rules" for essential skills not covered in most beginner books.
🚀 Embrace your "Right Way" of programming, but avoid making it your entire identity.
🤔 Distinguish between the technique and the way it's pitched; modify ideas to fit your needs.
📚 Investigate the origins of best practices to understand their relevance to your work.
🚶♂️ Regularly take walks to clear your mind and foster creativity.
🔍 Explore the hidden depths of tools you use, like programming languages and git.
🗣️ Interact with people in different company areas, like support and sales, to broaden your perspective.
🌐 Experience diverse programming roles early in your career to discover your preferences.
🌟 Understand that the fast spread of information in software can distort the popularity and utility of technologies.
🛣️ Be conservative with adopting new technologies unless they truly excite you.
🧭 Focus on living by your values and enjoying your career journey in software development.
How to uncover your users' real problems
🙋 Start with asking the right people: It's crucial to ask questions to the right audience to gain valuable insights. For instance, Twitch focused on streamers as their primary audience.
⏳ Choose the appropriate time and place: The timing and context of questions can significantly impact the usefulness of the answers. Amazon's use of post-purchase surveys is a good example.
🧐 Dive deeper with your questions: Avoid surface-level inquiries and focus on understanding the underlying issues or 'jobs to be done' that users face.
🙌 Simplify your questions: Ensure your questions are easy to understand and answer. This approach was effectively used by Uber in their surveys.
🔁 Ask repeatedly to track changes: Repeatedly asking the same questions can help in monitoring changes and ensuring you are on the right track, as practiced by Superhuman and Zola.
📝 Share discoveries and plan accordingly: It's important to share the feedback with your team and use it to make informed decisions and improvements in your product or service.