How do companies build Digital Products? What does it look like inside a developer-led company?
Jeff Lawson, a developer and successful startup founder, explores in detail the mindset and methodology needed to fully leverage the unique abilities of developers to build and grow competitive advantage.
He covers the strategic need for software-level differentiation and then digs into the practicalities of how to make it a reality.
Chapter 1 – Build Vs Die
Companies must face up to the fact that software may well be their key competitive advantage, regardless of which industry they are in. Any software that you rely on for competitive advantage or that touches the user experience should be built in house. You cannot differentiate your business by using something that is off the shelf because if it’s not unique to you, it’s not a differentiator.
Chapter 2 – The New Software Supply Chain
If Chapter 1 made you nervous, the good news is that building your own software is made easier by a comprehensive supply chain of “software parts” which developers can bring together to make something unique that serves your business. A business’ ability to adapt is only as good as its supply chain. When software is a differentiator for your offering, you must actively manage your Digital Supply Chain (which means giving developers the autonomy to do so).
Chapter 3 – Hi, I’m Jeff and I’m a Developer
Jeff is an entrepreneur and a developer who has founded several startups including Twilio and StubHub. He has also worked as an AWS Product Manager at Amazon. He is an example of a developer who used his development skills to solve business problems.
Chapter 4 – Code is Creative
Despite common stereotypes, developers aren’t socially inept and math-focused. They are creative and love problem solving – they want to make a difference. Developing software is highly creative work and is more of an art than a science. When given a 3600 view of a problem and the chance to step into the user’s shoes, developers can rapidly produce elegant solutions that meet the exact needs of the business and the user.
Chapter 5 – Experimentation is the Prerequisite to Innovation
To innovate, it’s necessary to create a culture of experimentation. This is done by framing business problems so that developers can quickly and cheaply test solutions to them. Instead of trying to de-risk projects upfront through high investment, you run a number of parallel innovation experiments that systematically validate (or invalidate) business models or solutions. Like a maze, finding the paths that don’t go anywhere is part of finding the ones that do, and spread-betting is more reliable in emerging situations.
To succeed in this approach you need processes and behaviors that support it. For example, accepting disproven hypotheses as good outcomes and not failures. Success in the experimentation phase is finding proven new business models, not revenue (which comes in the later, scaling phase).
Chapter 6 – Recruiting and Hiring developers
As creative, intelligent people, developers do not enjoy being shut away from the rest of the business or infantilized by offers of bean bags, ping pong tables and beer. They want the opportunity to be recruited to work on meaningful problems with other talented people. They want substantial autonomy, a chance to improve mastery and a purpose to motivate them. As with most people, compensation needs to be good enough to feel fair and not be used as the primary carrot for performance. Creating a transactional environment (treating them as “code monkeys”) is not conducive to creativity.
Chapter 7 – Creating an Open, Learning Environment
Learning is best achieved through doing. Structuring your business to allow leadership at all levels provides a deep bench of future leaders through providing both guardrails and support for people to learn the skills required. It’s important to have a commitment to curious, blameless root-cause analysis to find the problems in the system and not the individual. It’s possible to develop practices and habits to embed this mindset at a company.
Chapter 8 – Small Teams and Single-Threaded Leaders
It’s critical to retain the focus, passion and drive that small companies embody. As a company grows, the number of possible communication paths between people quickly becomes overwhelmingly large. As teams grow into departments it’s common for individuals to lose a lot of autonomy and access to the customer.
An alternative is to structure the company in small teams which have close collaboration inside them, and simpler more standardised or “contract-driven” communication in between them. Each team should have a defined Customer, Mission, and Metric, and a “single-threaded” (single focus) manager. As products grow their teams, purpose and codebase are split cleanly to allow for teams small enough to be fed by two pizzas (“the two-pizza team” is a common shorthand for this concept).
Chapter 9 – Wearing the Customers’ Shoes
As the company grows, it is important to continue to keep customer needs central and this must be done intentionally. It helps to open up direct channels of communication between customers and developers. Internally, customer-centric processes like writing unpublished (but realistic) press releases forces the writer to think in terms of customer value. Getting all parts of the business to spend time with customers builds empathy and context for better decision making.
Chapter 10 – Demystifying Agile
Agile software development was invented in 2001 to address the tendency for software projects to go way over time and budget.The old way prioritized certainty and fixed feature scope but failed on timeliness and quality. Agile focuses on timeliness and quality, while allowing certainty and feature scope to emerge along the way. This supports the overall ability of a company to remain adaptive and innovative with its differentiated software layer.
Agile methods focus on building frequently-delivered chunks of usable software. This allows changes to requirements to be made at any stage in a project. This fits much better with the natural tendency for knowledge and context to evolve over time. On the ground, Agile focuses on minimising the amount of work in flight and limiting the impact of meetings so that developers can get unbroken blocks of time for deep work in “flow” state – to work as makers.
Chapter 11 – Invest in Infrastructure
Infrastructure is not (just) hardware. It includes tools, and environments that automate or share common tasks. Duplication of tooling and other infrastructure is OK because it is an outcome of autonomy, which is more important than efficiency. Supporting emerging practices and “paving the cowpaths” is a legitimate means to achieving operational efficiency. In essence, favor guardrails not rules. Open source (internally) the tools to allow for customisation of “platform”. Platform teams/engineers need intentional investment.
Title | Ask Your developer: How to Harness the Power of Software developers and Win in the 21st Century |
Author | Jeff Lawson |
Date of publication | Feb 2021 |
Link to Purchase | https://www.amazon.co.uk/Ask-Your-developer-Software-Developers/dp/0063018292 |