As an engineering manager, you’re tasked with building awesome teams. You work tirelessly to help keep projects on track, meet deadlines, and deliver results. But lately, something feels off. Your team is undoubtedly busy, even productive by conventional measures. Yet, you can’t shake the nagging feeling that all this activity isn’t translating into meaningful impact for your business or your users.

If this resonates with you, your team might be caught in a cycle of prioritizing output over outcomes. Let’s explore what this looks like from a leadership perspective and why it’s a critical issue to address.

Signs of the Problem

1. Measuring Work Alone: Your team’s success is measured primarily by output – story points completed, tickets closed, features shipped. But what about the outcomes? Are you tracking the actual value these activities bring to the business?
2. Lack of Feedback: Features are developed, shipped to production, and marked as “done.” But then… silence. There’s no mechanism in place to gather feedback on whether these features are successful or even used.
3. Team Disconnection: Your developers are “shielded” from talking to business people. You might have heard the phrase, “Don’t interrupt our precious engineers’ time.” But this protection comes at a cost – disconnection from the very problems they’re trying to solve.
4. Deadline-Driven Development: Your team is constantly working towards deadlines handed down from above. The problem? No one on the team understands where these deadlines come from or why they’re important.
5. Product Overwork: Your Product Managers are spending so much time writing detailed specifications that you’re considering hiring people whose sole job is to create detailed specs for the engineers. This level of detail might seem helpful, but it can stifle creativity and problem-solving.

The Round Corners Saga: A Case Study

Let me share a story that might hit close to home. Your team has been working on a new user interface. In a recent sprint review, you’re surprised to learn that one of your engineers spent five days ensuring text boxes had perfectly rounded corners across all browsers and devices.

Proud of their attention to detail, your developer showcases the feature. But when you speak with the product owner, you discover that the round corners weren’t even a requirement – they were just a default style in the design tool’s mockups.

Five days of a skilled developer’s time, spent on an unintended, unnecessary detail. As a manager, how do you react? More importantly, how do you prevent this from happening again?

Here’s the thing: I don’t blame the engineer. I think it’s a fundamental problem that stems from the way we’re brought up, and more broadly, from Western-based education systems.

Think about it like this:

• As a child, you have your parents telling you what to do.
• In school, your teachers tell you what to do.
• At university, your lecturers tell you what to do.

You spend the first part of your life with people telling you what to do. So it’s only natural that people find it easy to get trapped into finding the next person to tell them what to do. And usually, in dev teams that do Scrum, this becomes their Product Owner or manager.

It’s the managers responsibility to coach this out of people.

The Real Costs

This way of working comes with significant costs:

1. Strategic Misalignment: Your team’s efforts aren’t driving towards key business objectives. You’re busy, but are you moving in the right direction?
2. Opportunity Cost: Time spent on unnecessary features or misguided efforts is time not spent on innovations that could provide a real competitive advantage.
3. Talent Retention Risk: Skilled developers often leave when they feel their work lacks purpose or impact. Are you at risk of losing your best people?

Solutions: Leadership for Purpose-Driven Development

As a leader, you have the power to shift your team’s focus from output to outcomes. Here’s how:

1. Reinforce the ‘Why’: Push your engineers to ask why. Why are we building this feature? Why is it important? Why now?
2. Redefine Success Metrics: Your Product Manager should already be doing this, but they might be hiding it from the engineers, I’ve seen this many times, some Product people think by doing this it’s less distracting for the engineers, but it has a negative effect. If they’re not doing it at all, you have bigger problems, and you probably need to go higher than your team to address them.
3. Encourage Customer Connection: Break down the barriers between your developers and the users they’re building for. Teach them who they serve, the customer, and if you can introduce them to some and get them talking to them.
4. Promote Learning Loops: Make time to analyze the impact of your work after it’s shipped. What worked? What didn’t? Why? Get your engineers engaged with the Analytics data that comes out of their system, get them excited about how many users are using their new feature, and if people aren’t, ask why?
5. Cross-Team Collaboration: And I don’t just mean in formal settings. Have a beer together sometimes. Build real relationships across teams, Engineers, Design, Product and other business units.

Understanding the “Feature Factory” Phrase

The term “feature factory” vividly illustrates a development process that prioritizes output over outcomes, quantity over quality. Like workers on an assembly line, developers in this environment might be busy but disconnected from the larger purpose of their work.

As a leader, your role is to transform this factory into an innovation studio – a place where each line of code contributes to a larger vision, where your team’s skills are applied to solving real problems, not just checking off feature lists.

Moving Forward

Recognizing that your team may be stuck in this output-focused mindset is a crucial first step. The next is to start changing the conversation at all levels – with your team, with product managers, with stakeholders.

Start asking different questions in your meetings:

• “How will we measure the success of this feature?”
• “What problem are we solving for our users?”
• “If this feature succeeds, what impact will it have on our key business metrics?”

Encourage your team to think beyond the immediate task to the larger purpose. Help them see their work not as isolated features, but as integral parts of a solution that brings real value to users and the business.

Remember, you became a leader to make a difference – to guide your team to create impactful, meaningful work. Don’t let the trap of focusing on output rob you and your team of that opportunity.

Are you ready to lead the change? Your team’s potential for true innovation and impact is waiting to be unleashed.

Before we dive into the process of splitting a monolith, it’s crucial to understand why monoliths can become problematic and when they might still be a good choice. In this post, we’ll explore the challenges that often arise with monolithic architectures and discuss scenarios where they might still be appropriate.

What’s So Bad About Monoliths?

Monolithic architectures, where all components of an application are interconnected and interdependent, can present several challenges as systems grow:

1. Development Feedback Loops

One of the most significant issues with large monoliths is the impact on development feedback loops:

• Compilation Time: Large codebases often take a long time to compile, slowing down the development process.
• Test Execution Time: With a vast number of tests, running the entire test suite can be time-consuming.
• Test Flakiness: As the number of tests grows, the overall stability of the test suite can decrease dramatically. For example:
  • If each individual test has a 99% stability rate (which sounds good),
  • In a suite with 179 tests, the actual stability rate becomes 0.99^179 ≈ 17%
  • This means there’s only a 17% chance of all tests passing in a given run!

2. Increased Lead Time

The factors mentioned above contribute to increased lead time for new features or bug fixes:

• Longer compile and test times slow down the development cycle.
• Large monoliths often require more server resources, leading to longer deployment times.

3. Framework Upgrades

Upgrading frameworks or libraries in a monolith can be a massive undertaking. Changes often need to be applied across the entire system simultaneously. the more code you have the more potential breaking change you need to fix in one go, the you have a large MR, and with high volume of change you normally get in big repos, good luck getting it merged with all the merge conflicts 🙂

The Pitfalls and Potential of Monolithic Architectures

Are Monoliths Ever Good?

Despite these challenges, monoliths aren’t always bad. In fact, they can be an excellent choice in certain scenarios:

1. Startups and Small Projects

Many large companies started with small monolithic applications. When you’re small and trying to “take on the world,” a monolith can be the fastest way to get a product to market. It allows for rapid development and iteration in the early stages of a product. This approach enables startups to focus on validating their business ideas and gaining market traction without the added complexity of a distributed system.

2. Simple Applications

For applications with straightforward requirements and minimal complexity, a monolith might be the most straightforward and maintainable solution. In such cases, the simplicity of a monolithic architecture can lead to faster development cycles and easier debugging, as all components are in one place.

3. Teams New to Microservices

If your team doesn’t have experience with distributed systems, starting with a well-structured monolith can be a good learning experience before moving to microservices. This approach allows the team to focus on building features and understanding the domain, while gradually introducing concepts like modularity and service boundaries within the monolith. As the team and application grow, this experience can make a future transition to microservices smoother and more informed.

Best Practices for Starting Small

If you’re starting a new project and decide to go with a monolithic architecture, here are some best practices:

1. Plan for Future Splitting: Design your monolith with clear boundaries between different functionalities, making future splits easier.
2. Use Modular Design: Even within a monolith, use modular design principles to keep different parts of your application loosely coupled.
3. Maintain Clean Architecture: Follow clean architecture principles to separate concerns and make your codebase more manageable.
4. Monitor Growth: Keep an eye on your application’s size and complexity. Be prepared to start splitting when you notice development slowing down or when the benefits of splitting outweigh the costs.

Conclusion

While monoliths can present significant challenges as they grow, they’re not inherently bad. The key is understanding when a monolithic architecture is appropriate and when it’s time to consider splitting. By being aware of the potential pitfalls and planning for future growth, you can make informed decisions about your application’s architecture.

In the next post, we’ll dive into the process of identifying business domains within your monolith, which is the first step in planning a successful split.

In our previous post, we explored the first set of essential skills for product engineers, focusing on non-technical abilities that bridge the gap between engineering and business. Today, we’ll dive into the second part of our essential skills series, covering more technically-oriented skills that are crucial for success in product engineering.

Data Analysis and Metrics

In the world of product engineering, data reigns supreme. This skill empowers engineers to make informed decisions, measure the impact of their work, and continuously improve product performance.

Metrics Definition is the foundation of effective data analysis. It’s not enough to simply collect data; you need to know which metrics are most relevant to your product and how they align with broader business goals. This requires a deep understanding of both the product and the business model. For instance, a social media application might focus on Daily Active Users (DAU) as a key engagement metric, along with other user interaction metrics like posts per user or time spent in the app. On the other hand, an e-commerce platform might prioritize conversion rates, average order value, and customer lifetime value. By defining the right metrics, engineers ensure that they’re measuring what truly matters for their product’s success.

The next step is Data Collection. This involves implementing systems to gather data accurately and consistently. It’s not just about collecting data, but ensuring its accuracy and integrity. Many engineers work with established analytics tools like Google or Adobe Analytics, which provide a wealth of user behavior data out of the box. However, for more specific or granular data needs, custom tracking solutions are necessary. This could involve instrumenting your code to log specific events or user actions. The key is to create a comprehensive data collection system that captures all the information needed to calculate your defined metrics.

With data in hand, the next skill is Statistical Analysis. While engineers don’t need to be statisticians, a basic understanding of statistical concepts is needed for interpreting data correctly. This includes grasping concepts like statistical significance, which helps determine whether observed differences in metrics are meaningful or just random noise. Understanding the difference between correlation and causation is also vital – just because two metrics move together doesn’t necessarily mean one causes the other. Handling outliers is another important skill, as extreme data points can significantly skew results if not treated properly. These statistical skills allow engineers to draw accurate conclusions from their data and avoid common pitfalls in data interpretation.

Data Visualization is where numbers transform into narratives. The ability to present data in clear, compelling ways is crucial for communicating insights to stakeholders who may not have a deep technical background. Tools like metabase, superset, grafana, etc offer powerful capabilities for creating interactive visualizations, while even simple Excel charts can be effective too. The goal is to make the data tell a story – to highlight trends, comparisons, or anomalies in a way that’s immediately understandable. Good data visualization can turn complex datasets into actionable insights, influencing product decisions and strategy.

A/B Testing is a technique in the engineer’s toolkit. It involves designing and implementing experiments to test hypotheses and measure the impact of changes. This could be as simple as testing two different button colors (one the A variant, the other the B) to see which drives more clicks, or as complex as rolling out a major feature to a subset of users to evaluate its impact on key metrics. Effective A/B testing requires understanding concepts like control groups (users who don’t receive the change), variable isolation (ensuring you’re testing only one thing at a time), and statistical power (having a large enough sample size to draw meaningful conclusions). Mastering A/B testing allows engineering teams to make data-driven decisions about feature development and optimization.

Performance Optimization

In today’s fast-paced digital world, user expectations for application performance have never been higher. Users demand fast, responsive applications that work seamlessly across devices and network conditions. As a result, performance optimization has become a critical skill for engineers. It’s not just about making things fast; it’s about creating a smooth, responsive user experience that keeps users engaged and satisfied, regardless of the complexity behind the scenes.

Profiling and Benchmarking form the foundation of effective performance optimization. Before you can improve performance, you need to understand where the bottlenecks are. This involves using a variety of tools to analyze your application’s performance characteristics. For front-end performance, browser developer tools provide powerful capabilities for analyzing load times, JavaScript execution, and rendering performance, chrome debugger and extensions allow testing stats like LCP, CLS, etc and debugging why they are bad locally, but don’t forget to measure RUM (Real User Metrics), getting data from your real user interactions. These tools can help identify slow-loading resources, long-running scripts, or inefficient DOM manipulations that might be causing performance issues.

On the backend, specialized profiling tools can help identify performance bottlenecks in server-side code or database queries. These tools like pyroscope, application insights and open telemetry tracing, might analyze CPU usage, memory allocation, or database query execution times to pinpoint areas for improvement. The key is to establish baseline performance metrics and then systematically identify the areas that have the biggest impact on overall application performance.

Once you’ve identified performance bottlenecks, the next step is applying Optimization Techniques. This is a topic for another post for sure, based on your environment this can vary greatly so I wont go into too much details today.

Google’s Core Web Vitals initiative is a prime example of the industry’s focus on performance and its impact on user experience. These metrics – Largest Contentful Paint (LCP), First Input Delay (FID), and Cumulative Layout Shift (CLS) – provide a standardized way to measure key aspects of user-centric performance. LCP measures loading performance, FID measures interactivity, and CLS measures visual stability. By focusing on these metrics, engineers can ensure they’re optimizing for the aspects of performance that most directly impact user experience.

For example, optimizing for Largest Contentful Paint might involve prioritizing the loading of above-the-fold content, while improving First Input Delay could involve breaking up long tasks in JavaScript to improve responsiveness to user interactions. Minimizing Cumulative Layout Shift often involves careful management of how content loads and is displayed, ensuring that elements don’t unexpectedly move around as the page loads.

The importance of these metrics extends beyond just providing a better user experience. Search engines like Google now consider these performance metrics as ranking factors, directly tying performance optimization to an application’s visibility and success.

Security and Privacy

Cyber threats are ever-evolving and privacy regulations are becoming increasingly stringent, security and privacy considerations must be at the forefront of a engineer’s mind. These are not just technical challenges, but fundamental aspects of building user trust and ensuring the long-term success of a product.

Threat Modeling is a proactive approach to security that involves anticipating and modeling potential security threats to your application. This process requires engineers to think like attackers, identifying potential vulnerabilities and attack vectors in their systems. It’s not just about considering obvious threats like unauthorized access, but also more subtle risks like data leakage or denial of service attacks. Effective threat modeling involves mapping out the system architecture, identifying assets that need protection, and systematically analyzing how these assets could be compromised. This process should be an ongoing part of the development lifecycle, revisited as new features are added or the system architecture evolves.

Secure Coding Practices are the foundation of building secure applications. This involves understanding and implementing best practices for writing code that is resistant to common security vulnerabilities. Input validation is a crucial aspect of this, ensuring that all data entering the system is properly sanitized to prevent attacks like SQL injection or cross-site scripting. Proper authentication and authorization mechanisms are essential to ensure that users can only access the resources they’re entitled to. Secure data storage practices, including proper encryption of sensitive data both at rest and in transit, are also critical. Engineers should be familiar with common security vulnerabilities (like those listed in the OWASP Top 10) and know how to mitigate them in their code.

Compliance Understanding has become increasingly important as privacy regulations have proliferated around the world. Engineers need at least a basic understanding of relevant privacy regulations like the General Data Protection Regulation (GDPR) in Europe or the California Consumer Privacy Act (CCPA) in the United States. This doesn’t mean engineers need to become legal experts, but they should understand how these regulations impact product development. For example, GDPR’s “right to be forgotten” requirement has implications for how user data is stored and managed. Understanding these regulations helps engineers make informed decisions about data handling and storage, and ensures that privacy considerations are factored into product design from the outset.

Security Testing is a important skill for ensuring that the security measures implemented are effective. This involves familiarity with various security testing tools and practices. Penetration testing, or “pen testing,” involves simulating attacks on a system to identify vulnerabilities. This can be done manually by security experts or using automated tools. Code security scanners are another important tool, analyzing code for potential security issues. Static Application Security Testing (SAST) tools can identify vulnerabilities in source code, while Dynamic Application Security Testing (DAST) tools can find issues in running applications. Engineers should be familiar with these tools and be able to interpret and act on their results.

Security and privacy are no longer optional considerations in engineering – they are fundamental requirements. As cyber threats continue to evolve and users become increasingly aware of privacy issues, the ability to build secure, privacy-respecting products will be a key differentiator for engineers.

Scalability and Reliability

As products grow and user bases expand, the ability to scale systems to meet increased demand while maintaining reliability becomes an important skill for engineers. This is not just about handling more users or data; it’s about ensuring that the product continues to perform well and provide a consistent user experience even as it grows exponentially.

Distributed systems involve multiple components working together across different networks or geographic locations to appear as a single, cohesive system to end-users. This approach allows for greater scalability and fault tolerance, but it also introduces complexities in areas like data consistency, network partitions, and system coordination. Engineers need to understand concepts like CAP theorem, and it’s proponents. They should be familiar with patterns like microservices architecture, moduliths, event sourcing, etc. and how these apply with scale.

Load Balancing and Caching are critical strategies for managing increased demand on systems. Load balancing has changed greatly in recent years, gone are teh days of a large “in front everywhere” infrastructure, in favour of load balancing sidecars now with tech like envoy, and in-front load balancing banished to the edges. Engineers should be familiar with different load balancing algorithms (like round-robin, least connections, etc.) and understand when to use each as well as how health checks work in these scenarios.

Caching, on the other hand, could involve in-memory caches like Redis, content delivery networks (CDNs) for static assets, or application-level caching strategies. Effective caching requires careful consideration of cache invalidation strategies to ensure users always see up-to-date information. Engineers should understand not only pull through cache but other forms such as write-through, etc and also when to prewarm and expire based on the data and user needs.

Database Scaling is often one of the most challenging aspects of growing a system. As data volume and read/write operations increase, a single database instance may no longer be sufficient. Engineers need to be familiar with various database scaling techniques. Vertical scaling (adding more resources to a single machine) can work up to a point, but eventually, horizontal scaling becomes necessary and presents many challenges and options that engineers should be familiar with to be able to make the right choice.

Chaos Engineering is a proactive approach to ensuring system reliability that has gained prominence in recent years. The core idea is to intentionally introduce failures into your system in a controlled manner to test its resilience. This helps identify weaknesses in the system that might not be apparent under normal conditions.

Netflix’s Chaos Monkey is a prime example of this approach. This tool randomly terminates instances in their production environment, forcing engineers to build systems that can withstand these types of failures. By simulating failures in a controlled way, Netflix ensures that their systems can handle unexpected issues in real-world scenarios.

Other forms of chaos engineering might involve simulating network partitions, inducing latency, or exhausting system resources. The key is to start small, build confidence, and gradually increase the scope of these experiments. This approach not only improves system reliability but also builds a culture of resilience within engineering teams.

The importance of scalability and reliability in product engineering cannot be overstated. As users increasingly rely on digital products for critical aspects of their lives and work, the cost of downtime or poor performance can be enormous, both in terms of lost revenue and damaged user trust.

Moreover, the ability to scale efficiently can be a key competitive advantage. Products that can quickly adapt to growing demand can capture market share and outpace competitors. On the flip side, products that struggle with scalability often face user frustration, increased operational costs, and missed opportunities.

Continuous Integration and Deployment (CI/CD)

CI/CD practices enable teams to deliver code changes more frequently and reliably, accelerating the feedback loop and reducing the risk associated with deployments.

Engineers need to be proficient in writing effective, efficient tests and understanding concepts like test coverage and why the test pyramid is flawed, and new concepts like the testing honey combe. They should also be familiar with testing frameworks and tools specific to their technology stack. The goal is to catch bugs early in the development process, reducing the cost and risk of fixing issues in production.

Continuous Integration (CI) means continuously integrating code, its not about your Jenkins or github actions pipeline, its about fast merging changes together. Git branches are counter to this principle, but necessary in order to facilitate change in manageable or deployable chunks. Good Engineers understand CI is a principle, not a build system, this help them focus on it’s purpose which is moving fast an efficiently.

Continuous Deployment (CD) key skills here include understanding deployment strategies like blue-green deployments or canary releases, which minimize risk and downtime during updates. Engineers need to be proficient in infrastructure-as-code tools like Helm, Terraform or CloudFormation to manage their infrastructure alongside their application code. They should also be familiar with containerization technologies like Docker and orchestration platforms like Kubernetes, which can greatly simplify the process of deploying and scaling applications.

Feature Flags have become an essential tool in modern CD practices. They allow teams to decouple code deployment from feature release, giving more control over when and to whom new features are made available. Engineers need to understand how to implement feature flag systems, which can range from simple configuration files to more complex, dynamically controllable systems. This involves not just the technical implementation, but also understanding the strategic use of feature flags for A/B testing, gradual rollouts, and quick rollbacks in case of issues. Proper use of feature flags can significantly reduce the risk associated with deployments and allow for more frequent, smaller releases.

The benefits of mastering CI/CD are significant. It allows teams to deliver value to users more quickly, reduce the risk associated with each deployment, and spend less time on manual, error-prone deployment processes. It also improves developer productivity and satisfaction by providing quick feedback on code changes and reducing the stress associated with large, infrequent releases.

Cross-Platform Development

In today’s diverse technological landscape, users access digital products through a multitude of devices and platforms. As a result, the ability to develop cross-platform solutions has become an increasingly valuable skill for product engineers.

Responsive Web Design (RWD) forms the foundation of cross-platform web development. It’s an approach to web design that makes web pages render well on a variety of devices and window or screen sizes. The core principle of RWD is flexibility – layouts, images, and cascading style sheet media queries are used to create a fluid design that adapts to the user’s screen size and orientation. They should also understand the principles of mobile-first design, which advocates for designing for mobile devices first and then progressively enhancing the design for larger screens.

Cross-Platform Frameworks have emerged for native mobile development as a popular solution for building mobile apps that can run on multiple platforms with a single codebase. Tools like React Native, Flutter and even Web View allow developers to write code once and deploy it to both iOS and Android, potentially saving significant development time and resources.

Proficiency in cross-platform frameworks requires not just knowledge of the framework itself, but also an understanding of the underlying mobile platforms. Engineers need to know when to use platform-specific code for certain features and how to optimize performance for each platform.

The choice between these different approaches – responsive web, native apps, cross-platform frameworks, or even PWAs – depends on various factors including the target audience, required features, performance needs, and development resources. Engineers need to understand the trade-offs involved in each approach and be able to make informed decisions based on the specific requirements of each project.

Moreover, the field of cross-platform development is rapidly evolving. New tools and frameworks are constantly emerging, and existing ones are regularly updated with new features. For example, Flutter has expanded beyond mobile to support web and desktop platforms as well. React Native is used in the PS5 UI now expanding its reach to home entertainment.

This constant evolution means that cross-platform development skills require ongoing learning and adaptation. Engineers need to stay updated with the latest developments in this field, continuously evaluating new tools and approaches to determine if they can provide benefits for their projects.

Conclusion

These technical skills – data analysis, performance optimization, security and privacy, scalability and reliability, CI/CD, and cross-platform development – form the backbone of an engineer’s technical toolkit. Combined with the non-technical skills we discussed in our previous post, they enable engineers to build products that are not only technically sound but also user-friendly, scalable, and aligned with business goals.

Remember, the field of product engineering is constantly evolving. The most successful engineers are those who commit to lifelong learning, always staying curious and open to new technologies and methodologies.

What technical skills have you found most valuable in your product engineering journey? How do you stay updated with the latest trends and technologies? Share your experiences and tips in the comments below!

In our previous posts, we’ve explored the evolution of product engineering, its core principles, and the mindset that defines successful product engineers. Now, let’s dive into the specific skills that product engineers need to thrive in their roles. This post, the first of two parts, will focus on four essential non-technical skills: goal setting and value targeting, decision making and risk assessment, understanding business models, and design thinking and empathy.

Goal Setting and Value Targeting

One of the most crucial skills for product engineers is the ability to set clear, meaningful goals and target value creation. This skill goes beyond simply meeting technical specifications or delivering features on time.

One of the hardest things about goal setting, is once you set a goal you set your conditions for failure, and no one like to fail, but this is part of the mindset we spoke about before, you need to be ok with failure, its a learning experience, you need to be ok with setting moonshot goals occasionally too.

Effective goal setting involves:

1. Alignment with business objectives: Goals should directly contribute to the company’s overall strategy and key performance indicators (KPIs).
2. User-centric focus: Goals should reflect improvements in user experience or solve specific user problems.
3. Measurability: Goals need to be quantifiable, allowing for clear evaluation of success.
4. Timebound nature: Setting realistic timelines helps maintain focus and urgency, and also set increments for fast feedback cycles

For example, instead of setting a goal like “Implement a new recommendation system,” an engineering team might frame it as “Increase user engagement by 20% within three months by implementing a personalized recommendation system.”

Value targeting involves identifying and prioritizing the work that will deliver the most significant impact. This requires a deep understanding of both user needs and business priorities. Engineering Teams must constantly ask themselves: “Is this the most valuable thing I could be working on right now?”

Decision Making and Risk Assessment

Product engineers often find themselves at the intersection of technical possibilities, user needs, and business constraints. In this complex environment, the ability to make effective decisions becomes a critical skill. It’s not just about choosing the best technical solution, but about finding the optimal balance between various competing factors.

One of the key aspects of decision making for engineers is adopting a data-driven approach. This involves utilizing both quantitative and qualitative data to inform decisions. Quantitative data might include metrics from A/B tests, performance benchmarks, or usage statistics. This hard data provides concrete evidence of how different options perform. However, it’s equally important to consider qualitative data, such as user feedback or expert opinions. These insights can provide context and nuance that numbers alone might miss. By combining both types of data, Engineers can make more holistic, well-informed decisions.

Another crucial aspect of decision making is the consideration of trade-offs. In the real world, there’s rarely a perfect solution that optimizes for everything. Instead, Engineers must navigate complex trade-offs. For example, they might need to balance the speed of development against the quality of the end product, or weigh short-term gains against long-term sustainability. The skill lies not just in recognizing these trade-offs, but in being able to evaluate them effectively. This often involves quantifying the potential impacts of different choices and making judgment calls based on the specific context of the project and the company’s overall strategy.

Reid Hoffman reflecting on his time at startups once said “Sometimes it’s not about deciding which fire you put out, its about deciding which ones you can let burn”, making trade offs can involve hard choices.

Stakeholder management is another key component of effective decision making. Engineers need to consider how their decisions will impact various stakeholders, from end-users to business teams to other engineering teams. This involves not just making the right decision, but also being able to communicate the rationale effectively. Engineers must be able to explain technical concepts to non-technical stakeholders, articulate the business impact of technical decisions, and build consensus around their chosen approach.

In traditional software development companies, they hire BAs to deal with the business and try to “shield” the engineers or Scrum masters to “keep the wolves at bay”, Product Engineering is about removing these layers, the engineers themselves have enough understanding that they can deal with the stakeholders and this make communication and decision making more effective.

Alongside decision making, risk assessment. In any project or initiative, there are always potential risks that could derail success. The ability to identify these risks, evaluate their potential impact, and develop mitigation strategies is vital.

Engineers need to be able to look at different technical approaches and understand their potential pitfalls. This might involve considering factors like scalability, maintainability, or compatibility with existing systems. It’s about looking beyond the immediate implementation and considering how a technical choice might play out in the long term.

Engineers also need to be able to assess business risks. This involves evaluating how technical decisions might impact business metrics or user satisfaction. For example, a technically elegant solution might be risky if it requires a steep learning curve for users, potentially impacting adoption rates.

Another important aspect of risk assessment is opportunity cost consideration. In the world of product development, choosing one path often means not pursuing others. Engineers need to recognize this and factor it into their decision making. This might involve considering not just the risks of a chosen approach, but also the potential missed opportunities from alternatives not pursued.

Google’s approach to “Moonshot Thinking” in their X development lab provides a great example of how to balance ambitious goals with thoughtful risk assessment. Engineers in this lab are encouraged to tackle huge problems and propose radical solutions – true “moonshots” that could revolutionize entire industries. However, this ambition is tempered with a pragmatic approach to identifying and mitigating risks. Engineers are expected to critically evaluate their ideas, identifying potential failure points and developing strategies to address them. This approach allows for bold innovation while still maintaining a realistic perspective on the challenges involved.

By developing strong skills in decision making and risk assessment, engineers can make choices that balance technical excellence with business needs and user expectations, while also managing potential risks and trade-offs. These skills are what separate great engineers from merely good ones, enabling them to drive real impact and innovation in their organizations.

Understanding Business Models

While product engineers are primarily focused on technical challenges, a solid understanding of business models has become increasingly important in today’s tech landscape. This knowledge isn’t about turning engineers into business experts, but rather about equipping them with the context they need to make decisions that align with the company’s strategy and contribute to its overall success. By understanding the business side of things, engineers can better prioritize their work, make more informed technical decisions on the spot with out escalating to get direction.

One of the key aspects of understanding business models is grasping how the company generates revenue. Revenue streams can vary widely depending on the nature of the business. Some companies rely on subscription models, where users pay a recurring fee for access to a product or service. Others may generate revenue through advertising, leveraging user attention to sell ad space. Transaction fees are another common revenue stream, particularly for e-commerce or financial technology companies. Some businesses may use a combination of these or have more unique revenue models. For engineers, understanding these revenue streams is crucial because it can inform decisions about feature development, user experience design, and system architecture. Especially around immediate systems they work on, they are able to easily related back work they are doing to impact on company bottom line.

Equally important is an understanding of cost structures. Every business has costs associated with delivering its product or service, and these can significantly impact the viability of different technical approaches. Common costs might include server infrastructure, data storage, customer support, etc. Product engineers need to be aware of how their technical decisions might impact these costs. For example, choosing a more complex architecture might increase development and maintenance costs, while optimizing for performance could reduce infrastructure costs, and conversely a negative performance impact or bug could lead to a escalation in support calls. By understanding the cost implications of their decisions, engineers can make choices that balance technical excellence with business sustainability.

Another crucial aspect of business models is understanding customer segments. Most products don’t serve a single, homogeneous user base, but rather cater to different groups of users with varying needs and behaviors. Engineers need to be aware of these different segments and how they interact with the product. This understanding can inform decisions about feature prioritization, user interface design, and even technical architecture. For instance, if a significant customer segment primarily uses the product on mobile devices, that might influence decisions about mobile optimization or the development of mobile-specific features.

Perhaps the most important element of a business model is the value proposition – the unique value that the company offers to its customers. This is what sets the company apart from its competitors and drives customer acquisition and retention. Engineers play a crucial role in delivering and enhancing this value proposition through the technical solutions they develop.

Let’s consider a concrete example to illustrate these concepts. Imagine you’re an engineer working at Spotify. Understanding Spotify’s business model would be crucial to your work. You’d need to know that Spotify operates on a freemium model, with both ad-supported free users and subscription-based premium users. This dual revenue stream (advertising and subscriptions) would inform many of your decisions.

For instance, when developing new features, you’d need to consider how they might impact the conversion rate from free to premium users. A feature that significantly enhances the listening experience might be reserved for premium users to drive subscriptions. On the other hand, a feature that increases engagement might be made available to all users to increase ad revenue from free users and make the platform more attractive to advertisers.

You’d also need to understand Spotify’s cost structure, particularly the significant costs associated with royalty payments to music rights holders. This might influence decisions about caching and data delivery to optimize streaming and reduce costs.

Understanding Spotify’s customer segments would be crucial too. You might need to consider the different needs of casual listeners, music enthusiasts, and artists using the platform. Each of these segments might require different features or optimizations.

Finally, you’d need to keep in mind Spotify’s value proposition of providing easy access to a vast library of music, personalized to each user’s tastes. Your technical decisions would need to support this, perhaps by focusing on recommendation algorithms, seamless playback, or features that enhance music discovery.

By understanding these aspects of Spotify’s business model, you as a engineer would be better equipped to make decisions that not only solve technical challenges but also drive the company’s success in a highly competitive market.

While engineers don’t need to become business experts, a solid grasp of business models is an increasingly valuable skill. It provides crucial context for technical decisions, helps in prioritizing work, and enables more effective collaboration with business stakeholders.

Design Thinking and Empathy

In the realm of product engineering, technical expertise alone is no longer sufficient to create truly impactful solutions. Enter design thinking: a problem-solving approach that places user needs and experiences at the center of the development process. For engineers, incorporating design thinking principles can lead to more innovative, user-friendly, and ultimately successful products.

Design thinking is not a linear process, but rather an iterative approach that encourages continuous learning and refinement. It typically involves five key elements, each of which plays a crucial role in developing user-centered solutions:

The first step is to Empathize. This involves deeply understanding the user’s needs, wants, and pain points. It’s about stepping into the user’s shoes, observing their behaviors, and listening to their experiences. For engineers, this might involve conducting user interviews, analyzing user data, or even spending time using the product as a user would. The goal is to uncover insights that may not be immediately apparent from technical specifications or feature requests.

Next comes the Define stage. Here, the insights gathered during the empathy stage are synthesized to clearly articulate the problem that needs to be solved. This is not about jumping to solutions, but about framing the problem in a way that opens up possibilities for innovative approaches. For engineers, this might involve reframing technical challenges in terms of user needs or business objectives.

The third stage is Ideation. This is where creativity comes to the forefront. The goal is to generate a wide range of possible solutions, without judgment or constraint. Techniques like brainstorming, mind mapping, or even role-playing can be used to spark new ideas. For engineers, this stage is an opportunity to think beyond conventional technical solutions and consider novel approaches that might better serve user needs.

Following ideation comes Prototyping. This involves creating quick, low-fidelity versions of potential solutions. The key here is speed and simplicity – the goal is not to build a perfect product, but to create something tangible that can be tested and refined. For engineers, this might involve creating basic wireframes, simple mock-ups, or even paper prototypes. The focus is on making ideas concrete enough to gather meaningful feedback.

The final stage is Testing. This is where prototypes are put in front of real users to gather feedback. It’s a critical stage that often leads back to earlier stages as new insights emerge. For engineers, this might involve conducting user testing sessions, analyzing usage data from beta releases, or going to a coffee shop and conducting guerilla testing session on patrons in exchange for buying them a coffee. The key is to approach this stage with an open mind, ready to learn and iterate based on user responses.

While all stages of design thinking are important, empathy deserves special attention as it forms the foundation of this approach. For engineers, developing empathy is about more than just understanding user requirements – it’s about truly connecting with the user’s experience.

User perspective is a crucial aspect of empathy. This involves the ability to see the product from the user’s point of view, understanding their context, motivations, and frustrations. It’s about asking questions like: What is the user trying to achieve? What obstacles do they face? How does our product fit into their broader life or work? By adopting the user’s perspective, engineers can make design and technical decisions that truly serve user needs, rather than just meeting specifications.

Diverse user consideration is another key aspect of empathy in product engineering. Users are not a monolithic group – they have diverse needs, abilities, and contexts. Some users might be tech-savvy early adopters, while others might be less comfortable with technology like your Aunty perhaps. Some might be using the product in resource-constrained environments, like low bandwidth internet in remote areas. Recognizing and considering this diversity in product development is crucial for creating truly inclusive and accessible products.

IDEO, the design company that popularized design thinking, emphasizes “human-centered design” as a cornerstone of their approach. Their methodology involves immersing themselves in the user’s world to gain deep, empathetic insights that drive innovation. This might involve spending time in users’ homes or workplaces, observing their behaviors and interactions with products in their natural environment. For engineers, adopting a similar approach – even if less intensive – can yield valuable insights that inform technical decisions and lead to more user-friendly solutions.

Design thinking can help engineers navigate the increasing complexity of modern product development. In a world where technical possibilities are vast and user expectations are high, design thinking provides a framework for focusing on what truly matters – creating solutions that make a meaningful difference in users’ lives.

Conclusion

These skills – goal setting and value targeting, decision making and risk assessment, understanding business models, and design thinking and empathy – form the foundation of a product engineer’s non-technical toolkit. They enable engineers to not just build products, but to create solutions that genuinely meet user needs and drive business success.

In our next post, we’ll explore the second set of essential skills for product engineers, including data analysis, A/B testing, and more. Stay tuned!

What’s your experience with these skills in your engineering work? How have you seen them impact product development? Share your thoughts and experiences in the comments below!