What do you think?
Rate this book
Ask Your Developer: How to Harness the Power of Software Developers and Win in the 21st Century
Jeff Lawson, software developer turned CEO of Twilio, creates
a new
playbook for unleashing the full potential of software developers in any organization, showing how to help management utilize this coveted and valuable workforce to enable growth, solve a wide range of business problems and drive digital transformation.
From banking and retail to insurance and finance, every industry is turning digital, and every company needs the best software to win the hearts and minds of customers. The landscape has shifted from the classic build vs. buy question, to one of build vs. die. Companies have to get this right to survive. But how do they make this transition?
Software developers are sought after, highly paid, and desperately needed to compete in the modern, digital economy. Yet most companies treat them like digital factory workers without really understanding how to unleash their full potential. Lawson argues that developers are the creative workforce who can solve major business problems and create hit products for customers—not just grind through rote tasks. From Google and Amazon, to one-person online software companies—companies that bring software developers in as partners are winning. Lawson shows how leaders who build industry changing software products consistently do three things well. First, they understand why software developers matter more than ever. Second, they understand developers and know how to motivate them. And third, they invest in their developers' success.
As a software developer and public company CEO, Lawson uses his unique position to bridge the language and tools executives use with the unique culture of high performing, creative software developers. Ask Your Developer is a toolkit to help business leaders, product managers, technical leaders, software developers, and executives achieve their common goal—building great digital products and experiences.
How to compete in the digital economy? In short: Ask Your Developer.
From banking and retail to insurance and finance, every industry is turning digital, and every company needs the best software to win the hearts and minds of customers. The landscape has shifted from the classic build vs. buy question, to one of build vs. die. Companies have to get this right to survive. But how do they make this transition?
Software developers are sought after, highly paid, and desperately needed to compete in the modern, digital economy. Yet most companies treat them like digital factory workers without really understanding how to unleash their full potential. Lawson argues that developers are the creative workforce who can solve major business problems and create hit products for customers—not just grind through rote tasks. From Google and Amazon, to one-person online software companies—companies that bring software developers in as partners are winning. Lawson shows how leaders who build industry changing software products consistently do three things well. First, they understand why software developers matter more than ever. Second, they understand developers and know how to motivate them. And third, they invest in their developers' success.
As a software developer and public company CEO, Lawson uses his unique position to bridge the language and tools executives use with the unique culture of high performing, creative software developers. Ask Your Developer is a toolkit to help business leaders, product managers, technical leaders, software developers, and executives achieve their common goal—building great digital products and experiences.
How to compete in the digital economy? In short: Ask Your Developer.
299 pages, Kindle Edition
Published January 12, 2021
412 people are currently reading
2631 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 142 reviews
Read
April 1, 2021It's a good (or even a very good) book if you meet certain criteria:
* you're an executive/decisive person in a typical enterprise that runs in a traditional model and gets beaten by disruptors or more "digital" competitors
* you're a business person who'd like to understand why everyone claims that every company is a tech company now (and what does software engineering has in common with that)
* you'd like to learn (but for real) what people originally had on their mind when using the phrase "digital revolution" and you're tired of all the weasel consultants trying to sell you their bullshit
On the other hand: it's not a book for tech people or start-up enthusiasts (who already understand how start-ups operate). They will not find it very revealing (but they will ofc agree with the content).
The book has been written by the CEO of Twilio, but it's not a praise litany for that company. Obviously, they are there all the time, in the background, but always for an illustratory purpose.
* you're an executive/decisive person in a typical enterprise that runs in a traditional model and gets beaten by disruptors or more "digital" competitors
* you're a business person who'd like to understand why everyone claims that every company is a tech company now (and what does software engineering has in common with that)
* you'd like to learn (but for real) what people originally had on their mind when using the phrase "digital revolution" and you're tired of all the weasel consultants trying to sell you their bullshit
On the other hand: it's not a book for tech people or start-up enthusiasts (who already understand how start-ups operate). They will not find it very revealing (but they will ofc agree with the content).
The book has been written by the CEO of Twilio, but it's not a praise litany for that company. Obviously, they are there all the time, in the background, but always for an illustratory purpose.
January 23, 2021
First half of the book was Twilio history, and its place within the context of software development history. Loved this, A+.
Second half was more or less a manifesto on how to run a more efficient and energizing software organization. I was a big fan of this, but YMMV - this is really geared towards folks who are (1) execs trying to get the most out of their software engineering orgs, or (2) Founders looking for some inspiration on how to run development. I think Product Managers might get some value out of this too, though some of the descriptions of a ‘bad’ software process might hit too close to home for some.
It definitely triggered some of my Amazon PTSD, but was also inspiring as someone embarking on a new startup project.
4/5 depending on your context!
Second half was more or less a manifesto on how to run a more efficient and energizing software organization. I was a big fan of this, but YMMV - this is really geared towards folks who are (1) execs trying to get the most out of their software engineering orgs, or (2) Founders looking for some inspiration on how to run development. I think Product Managers might get some value out of this too, though some of the descriptions of a ‘bad’ software process might hit too close to home for some.
It definitely triggered some of my Amazon PTSD, but was also inspiring as someone embarking on a new startup project.
4/5 depending on your context!
November 16, 2021
For most people this may be a 4 star, but, for me (A technology professional who believes in the power of developers and software making all things impossible, possible) it is 5 stars. The book covers with examples how software is eating the world, how developers are making technology decisions at companies, how developers are artists and innovate in healthy environments, how companies should think of the software creativity advantage and setup approaches to harness the best developers have to offer while helping developers create, deliver, learn, grow, and thrive. I recommend this to engineering managers and leaders, business leaders who want to create a competitive edge through software and anyone who considers themselves a citizen of the developer nation!
January 24, 2021
This was a guide aimed at teaching managers in legacy companies how to work with developers, though also acted as a thought leadership piece to attract customers and developers to Twilio.
Had some useful points, but could’ve definitely been a 3-part blog post.
- Running experiments and iterating quickly is everything right now. outsourcing to agencies or hiring consultants to make software won’t do. It’s slow, expensive, and generally doesn’t get you the results you need. Outsourcing also significantly reduces your speed of iteration
- We’re moving away from solutions to enabling building blocks. With these, we can empower internal teams to do so much more with their talents. With solutions, there was little scope for change
- For business people to work together with developers, they should share problems and not solutions. Don’t ask them to grind out the code. Just communicate the problem. Then, let create their own specifications and just vet the specifications to make sure they address the problem
- Management: Have small teams with single threaded leaders. Then, have well documented “communication APIs” to foster effective communication across teams
Had some useful points, but could’ve definitely been a 3-part blog post.
- Running experiments and iterating quickly is everything right now. outsourcing to agencies or hiring consultants to make software won’t do. It’s slow, expensive, and generally doesn’t get you the results you need. Outsourcing also significantly reduces your speed of iteration
- We’re moving away from solutions to enabling building blocks. With these, we can empower internal teams to do so much more with their talents. With solutions, there was little scope for change
- For business people to work together with developers, they should share problems and not solutions. Don’t ask them to grind out the code. Just communicate the problem. Then, let create their own specifications and just vet the specifications to make sure they address the problem
- Management: Have small teams with single threaded leaders. Then, have well documented “communication APIs” to foster effective communication across teams
March 1, 2021
This book completely encapsulates the frustrations I have seen over my entire consulting career in trying to demonstrate a vision of how to innovate. It also details a better roadmap for showing others how to achieve breakthroughs and the tools to do so. Namely, by creating a culture of experimentation and creativity from the onset.
I am a big believer in the concept of the “Aggregation of Marginal Gains.” A core tenant of this philosophy is tweaking little things to get 1% improvements that compound when put together. To identify these one percent improvements, you need to be creative and willing to experiment, a lot. You also have to be ok with things not working out. These “failures” should be learning opportunities and not blame sessions.
Those two key principles are what was missing from the conference room in a lot of my customer engagements. Jeff Lawson does a great job of showing how the old top down, failure is not option, big business approach is getting eaten alive by startups who do the opposite. Especially, when it comes to giving developers the space to creatively solve problems through experimentation and not requirements documents.
I am a big believer in the concept of the “Aggregation of Marginal Gains.” A core tenant of this philosophy is tweaking little things to get 1% improvements that compound when put together. To identify these one percent improvements, you need to be creative and willing to experiment, a lot. You also have to be ok with things not working out. These “failures” should be learning opportunities and not blame sessions.
Those two key principles are what was missing from the conference room in a lot of my customer engagements. Jeff Lawson does a great job of showing how the old top down, failure is not option, big business approach is getting eaten alive by startups who do the opposite. Especially, when it comes to giving developers the space to creatively solve problems through experimentation and not requirements documents.
November 2, 2021
I’m biased because I work for — and tremendously respect — Jeff Lawson, but…this book is awesome! Great overview of how software is reshaping our lives and economy and the role developers play in it. And: Twilio!!! I recommend the audiobook because Jeff is an authentic and lively narrator.
February 23, 2021
The little there was information about the Twilio way of doing things was really insightful. For example, the last chapter about devops was a great read/listen to someone not technical like me.
But then there were the numerous pages dedicated to motivate legacy companies to do “digital transformation” (5-10 years late?), to cover the history of software development, to explain agile development, to promote building on Twilio. This book tries to cover too much to too many audiences. I wish there would have been more specifics about .. asking the developers.
But then there were the numerous pages dedicated to motivate legacy companies to do “digital transformation” (5-10 years late?), to cover the history of software development, to explain agile development, to promote building on Twilio. This book tries to cover too much to too many audiences. I wish there would have been more specifics about .. asking the developers.
September 17, 2021
Perhaps it's because I have been a software developer -- who, as Jeff describes, are some of the most critical, cynical, and curmudgeonly folks on the face of the planet -- that I look askance at most books (supposedly) written by CEOs. They're often filled with tautologies and non-actionable aphorisms, avoid discussing any mistakes (hello, survivor bias!) and on top of everything, are ghostwritten by lowly interns, while the business leader gets to bask in the glory of "having a book". Well, let me tell you that Jeff's book is none of these things. As both a developer and the CEO of a multi-billion dollar public company, Jeff is both authentic and a great communicator to the book's audience: business executives needing education on software developers and how the relationship between "the business" and "engineering" must be improved.
I also highly appreciated Jeff's simplification of some of the management principles at Amazon, which were also described in Working Backwards. But in that book, they were sometimes (not always) described in an inscrutable way, and Jeff Bezos was often positioned as a tyrant. Jeff (Lawson) comes across as a kinder, gentler, less megalomaniacal (i.e. more mission oriented) version of Bezos, yet one gets the sense that he's no less demanding as a CEO. But he comes at it from a more community-oriented perspective, that excellence in execution results in great outcomes for everyone, rather than just for one person (Bezos) and as such was more personally convincing to me.
I've worked in software for my entire career, so none of the approaches that Jeff described are terribly new to me. But this is definitely a primer that I would give to any executive looking to understand digital transformation and isn't even aware that their previous treatment of developers as a set of untrained monkeys is not only damaging to their business, it is fatal.
I also highly appreciated Jeff's simplification of some of the management principles at Amazon, which were also described in Working Backwards. But in that book, they were sometimes (not always) described in an inscrutable way, and Jeff Bezos was often positioned as a tyrant. Jeff (Lawson) comes across as a kinder, gentler, less megalomaniacal (i.e. more mission oriented) version of Bezos, yet one gets the sense that he's no less demanding as a CEO. But he comes at it from a more community-oriented perspective, that excellence in execution results in great outcomes for everyone, rather than just for one person (Bezos) and as such was more personally convincing to me.
I've worked in software for my entire career, so none of the approaches that Jeff described are terribly new to me. But this is definitely a primer that I would give to any executive looking to understand digital transformation and isn't even aware that their previous treatment of developers as a set of untrained monkeys is not only damaging to their business, it is fatal.
April 24, 2021
I wish every founder to have it, not on his bookshelf, on his desk...
March 20, 2022
This book talks about the imp of developers in this digital world, walks you through their psyche and how they work & what motivates them. Author is the founder of Twilio. Pretty good read for someone from a non-software background.
July 11, 2022
This book is only useful if you are a non-technical VP at Proctor & Gamble (or another dinosaur) and you just recently learned the word “SaaS.” If you don't fit that description, then don't waste your money or time on this book.
December 2, 2022
As a non-technical founder of a venture-backed seed stage tech startup, let me share some concrete takeaways that we implemented based on this book. Bit of context, we're a business to consumer venture based out of Singapore with a developer team in India. Remote engagement is another barrier for us, as it is for many startups with lower cost developer teams. This book therefore added a lot of value for our developers and for me. Here are my key takeaways:
1) Autonomy: The overarching theme is to provide developers with trust via autonomy, a sense of deeper purpose and ownership, and eventually "mastery" over a particular domain over time. I love these 3 pillars and believe they can apply to any team. He breaks these out into several points, here were the two I implemented:
(a) Give them a break: Dev teams need to code, not constantly be on update calls. Give them breaks and therefore show trust in their ability to deliver.
(b) Split teams into pods of developers, don't assign large teams to a project as the marginal productivity of each additional Developer drops to a point where they actually hamper speed and quality
2) Run commercial decisions by developers. On the note of autonomy, he suggests something radical most organizations don't do:
(a) Give a problem, not a solution: he talks about not dictating solutions via a product manager, but instead involving the dev team in the problem statement itself. I liked his idea of walking around and asking developers "what problem are you solving?". I articulate our master problem statement in every monthly team calls now, and also often ask in 1-1 what they're working on and what problem they're solving.
(b) Involve developers at ideation stage: If not the problem stage, run a list of solutions by the Dev team and get their opinions. They will also feel more ownership.
(c) Hold mini-hackathons: We now provide 2 problem statements every 2 months, and ask the Dev team to come up with a unique solution. They don't need to code it, a word doc or Figma screens will do just fine.
3) Invest in infrastructure: Hire dev-ops to fix servers and back-end, vs focusing on new features and front-end. This is a difficult trade-off for early stage startups, we find ourselves constantly hitting a new growth milestone and then stumbling over new customers who hate the number of crashes. He highlights how Zuckerburg corrected his "Move fast and break things" to a more sustainable outlook on growth, which he recommends most startups also take up irrespective of stage. I don't fully agree with this as it's a fine balance, but we've also seen the downside of fast growth harming our image, as we didn't fix the infrastructure first.
4) Sprint/Agile planning: This topic is full of buzzwords depending on the source one reads. Jeff's description non-prescriptive and it shared some broad principles around breaking up tasks in to smaller sprints, keeping frequent smaller releases as a goal, and ensuring upward feedback happens regularly from all developers.
There are more talking points in this book but I'm sharing concrete steps we undertook to engage our dev team more and unleash their creativity. I definitely recommend reading this book for startup founders at any stage.
1) Autonomy: The overarching theme is to provide developers with trust via autonomy, a sense of deeper purpose and ownership, and eventually "mastery" over a particular domain over time. I love these 3 pillars and believe they can apply to any team. He breaks these out into several points, here were the two I implemented:
(a) Give them a break: Dev teams need to code, not constantly be on update calls. Give them breaks and therefore show trust in their ability to deliver.
(b) Split teams into pods of developers, don't assign large teams to a project as the marginal productivity of each additional Developer drops to a point where they actually hamper speed and quality
2) Run commercial decisions by developers. On the note of autonomy, he suggests something radical most organizations don't do:
(a) Give a problem, not a solution: he talks about not dictating solutions via a product manager, but instead involving the dev team in the problem statement itself. I liked his idea of walking around and asking developers "what problem are you solving?". I articulate our master problem statement in every monthly team calls now, and also often ask in 1-1 what they're working on and what problem they're solving.
(b) Involve developers at ideation stage: If not the problem stage, run a list of solutions by the Dev team and get their opinions. They will also feel more ownership.
(c) Hold mini-hackathons: We now provide 2 problem statements every 2 months, and ask the Dev team to come up with a unique solution. They don't need to code it, a word doc or Figma screens will do just fine.
3) Invest in infrastructure: Hire dev-ops to fix servers and back-end, vs focusing on new features and front-end. This is a difficult trade-off for early stage startups, we find ourselves constantly hitting a new growth milestone and then stumbling over new customers who hate the number of crashes. He highlights how Zuckerburg corrected his "Move fast and break things" to a more sustainable outlook on growth, which he recommends most startups also take up irrespective of stage. I don't fully agree with this as it's a fine balance, but we've also seen the downside of fast growth harming our image, as we didn't fix the infrastructure first.
4) Sprint/Agile planning: This topic is full of buzzwords depending on the source one reads. Jeff's description non-prescriptive and it shared some broad principles around breaking up tasks in to smaller sprints, keeping frequent smaller releases as a goal, and ensuring upward feedback happens regularly from all developers.
There are more talking points in this book but I'm sharing concrete steps we undertook to engage our dev team more and unleash their creativity. I definitely recommend reading this book for startup founders at any stage.
January 5, 2022
This book was good, however I think it makes more sense for someone at an executive level to read. If you have ever worked in tech closer to the ground level, a lot of this stuff is common sense. It wasn't a revelation for me to understand that developers are.... *checks notes* people too!? If you don't totally understand development or code, you can still understand what this book is trying to say. Treat your developers like the creative and skilled employees they are.
It was refreshing to hear Jeff Lawson's insights and stories from the beginning of his career and to his current role as CEO of Twilio. Hopefully managers and executives read this book and learn a thing or two from it as there are some useful tips regarding execution with small teams, having everyone work in customer service for their first few weeks at the company, and... ask your developer for solutions... like actual customer solutions (not just technical solutions to the pre-determined 'customer' solutions).
I know that roughly only 12% of engineers in Silicon Valley are women, but I couldn't not be annoyed by the fact that there was little to none anecdotal references from women in this book.
Overall I'd recommend, but I wasn't blown away.
It was refreshing to hear Jeff Lawson's insights and stories from the beginning of his career and to his current role as CEO of Twilio. Hopefully managers and executives read this book and learn a thing or two from it as there are some useful tips regarding execution with small teams, having everyone work in customer service for their first few weeks at the company, and... ask your developer for solutions... like actual customer solutions (not just technical solutions to the pre-determined 'customer' solutions).
I know that roughly only 12% of engineers in Silicon Valley are women, but I couldn't not be annoyed by the fact that there was little to none anecdotal references from women in this book.
Overall I'd recommend, but I wasn't blown away.
January 24, 2022
Companies need collaboration between people from both business and engineering. Multidisciplinary synergy is vital to guarantee a future in a digital world, where survival is dictated by the ability to experiment, innovate and build software, empowering people at all levels of a company that has a well-defined north.
The software is no longer a cost, it is the source of income, if this is not clear the risk of succumbing increases high.
In complex fast-moving environments, such as successful businesses and other processes in life, they require a very good knowledge of the ecosystem where they operate, a very good knowledge of the supply chain in the correct terms and contexts (digital supply chain)
Developing code with Creativity is a must and vital, bad software is imposed, when there is no freedom to solve problems. There could be a foggy line in being able to be a creative developer and not to do the work for someone for free, in that aspect it is very important to have the right people around.
To sustain creativity, the most important factor is knowing how to formulate a problem in a captivating, challenging and true way. Respecting the boundaries between problems and solutions.
Being able to experiment systematically, greatly increases the chances of success.The experiments that do not have clear metrics must be followed closely to react quickly in a stop or go.
Amazing, Fantastic nowadays book.
The software is no longer a cost, it is the source of income, if this is not clear the risk of succumbing increases high.
In complex fast-moving environments, such as successful businesses and other processes in life, they require a very good knowledge of the ecosystem where they operate, a very good knowledge of the supply chain in the correct terms and contexts (digital supply chain)
Developing code with Creativity is a must and vital, bad software is imposed, when there is no freedom to solve problems. There could be a foggy line in being able to be a creative developer and not to do the work for someone for free, in that aspect it is very important to have the right people around.
To sustain creativity, the most important factor is knowing how to formulate a problem in a captivating, challenging and true way. Respecting the boundaries between problems and solutions.
Being able to experiment systematically, greatly increases the chances of success.The experiments that do not have clear metrics must be followed closely to react quickly in a stop or go.
Amazing, Fantastic nowadays book.
August 16, 2021
I really liked this book! It’s been a (very long) while since I’ve read a business book and it was so refreshing. I’m not savvy about the tech industry or anything to do with developers since it’s not my industry so I found a lot of it enlightening in how things work (at least in some companies). I also found myself thinking more out-of-the-box and creatively in regards to the industry I used to work in. I felt like I always had things I wanted to talk about with my husband (who works for Twilio in marketing, not as a developer) both regarding the company itself and just cool things Jeff brought up in the book. Definitely a fun, enjoyable read that seemed useful from my ignorant perspective.
March 24, 2025
As a software developer the book really resonated, the book gives you an everything stew on software development, leadership, and entrepreneurship. Personally I really liked the part in which Jeff tells that should treat developers as artists, and letting them autonomously craft there software. The book was written pre-GenAI, so I feel that some of the core concepts have changed a lot. I would definitely like an updated version of it. Overall it's a fun read if you're a developer, so I would recommend it.
July 5, 2021
I enjoyed this book. It is an excellent playbook on how to setup and organize a tech company. There were no revolutionary new insights but covered all the fundamentals really well. 95% of the book was material I've heard elsewhere, but I still took away a couple new ideas and I would recommend this to other tech leaders.
July 26, 2021
It's a nice read for everyone, not just "tech people, to get a nice understanding of how Twillio push it's company and it's developers to build great user focus centric products with top innovation, quality and why not... inher joy of each employee.
March 26, 2022
This book nails so many topics: engineers are not only the Big Bang theory characters, give people problems not solutions, hire smart creatives and foster creativity and have a platform team to help teams focus on the important.
December 19, 2020
Great read so insightful thoughts
January 24, 2022
Mostly targeted to managers but explains clearly and in a short way how to make developers happy and productive, with a lot of real life examples
August 17, 2021
# Summary
Jeff Lawson "Ask Your Developer" is a playbook on how to make a company can leverage the important role of developer and how to set and environment to make developer can thrive in helping building a great business. This is the first business book that I know which focusing on the role of developer in business.
Jeff started the book discussing on how digital economy revolution that is happening now has made software shifted from cost center into profit center, from back office to the face of company. With this shifts, developer is under spotlights and becomes a really important actor in the revolution.
Ask your developer are divided into three main parts:
- The importance of developers
- How to motivate developers
- Making developers successful
The ideas are presented with the context of Jeff experience in building Twillio. Twillio is Platform as a service (PaaS) company that provides API integration related to communications such as phone call or text messages.
These are some great ideas from the book:
- In deciding build and buy software:
- The only things companies should build themselves are the things that are core to their business.
- Anything that gives you differentiation with customers, you should build.
- Anything that is customer-facing, you should build.
- Involve developer directly in solving business problem. Share the problems directly and not specification document.
- The most important things for developer (after money 🙂): Autonomy, Mastery, and Purpose
- Autonomy means the ability to work independently and not be told what to do.
- Mastery means the ability to get better at your craft over time.
- Purpose involves the feeling that the work you do actually matters.
The book is a must read for founders and developers.
# Highlights
437
11/8/2021 11:25:19 pm
Bunq’s founder and CEO, Ali Niknam,
528
11/8/2021 11:31:55 pm
That’s another reason why big corporations are so reluctant to change and why they continue to lag behind startups—because the top brass has a “shame and blame” culture, and the people who run the tech group don’t want to take risks.
642
11/8/2021 11:39:57 pm
Its founder and CEO, Marc Benioff, interned as an assembly language programmer at Apple (translation: he was a hard-core coder) and after university joined Oracle, where he quickly became a legendary salesman.
749
11/8/2021 11:47:49 pm
So Amazon started ascribing a cost to using these services, even internally. Some people call this transfer pricing, but in fact it’s a system of doing two things: holding teams accountable for their costs, and deciding where to put more resources in budget cycles.
784
11/8/2021 11:50:11 pm
**The only things companies should build themselves are the things that are core to their business.**
786
11/8/2021 11:50:27 pm
**My rule of thumb is that for anything that gives you differentiation with customers, you should build.**
794
11/8/2021 11:51:03 pm
**anything that is customer-facing, you should build.**
817
11/8/2021 11:52:33 pm
In fact, people have theorized about the “one-person unicorn,” meaning a company that is valued at $1 billion or more but is run by one person—a developer whose app sits on top of all those commercial microservices.
951
12/8/2021 12:14:22 pm
I’ve always thought that the best way to learn something new was to commit yourself to “customers” and force yourself to learn.
1087
12/8/2021 12:24:49 pm
leaders. S3 was informally led by Al Vermeulen,
1087
12/8/2021 12:24:59 pm
Al Vermeulen, Amazon’s CTO.
1114
12/8/2021 12:27:45 pm
This is how innovation works: experimentation is the prerequisite to innovation. The more quickly and cheaply you can run experiments, the faster you’ll eventually find something that works. So I kept looking for ideas.
1185
12/8/2021 12:32:59 pm
I’ve learned that the key ingredient to unlocking innovation is cultural more than anything
1185
12/8/2021 12:33:10 pm
the key ingredient to unlocking innovation is cultural more than anything else, and that culture starts at the top.
1267
12/8/2021 12:38:36 pm
Joe Rogan, who launched a free podcast in 2009 and in 2020 inked a $100 million deal with Spotify;
1309
12/8/2021 1:18:53 am
When you think of software developers, instead of Urkel, Sheldon, or Dennis Nedry, think of Patrick McKenzie, Ryan Leslie, Leah Culver, and Chad Etzel.
1363
12/8/2021 1:23:15 am
**Share problems, not solutions with your developers.**
1381
12/8/2021 1:24:40 am
‘Scientists find problems, and engineers fix problems.’ That’s always been my outlook on software engineers. They’re problem solvers.
1535
12/8/2021 11:43:57 am
When developers actually care about their work, intrinsic motivation kicks in and unlocks new and even more creative ideas.
1536
12/8/2021 11:44:10 am
When a developer is merely reading a specification document, they become isolated from the people who will use the software.
1623
12/8/2021 11:50:37 am
increasing the GDP of the Internet,
1680
12/8/2021 11:53:17 am
bringing developers into the big problems you’re trying to solve, and leveraging their full brains.
1750
13/8/2021 2:30:04 am
The only reason I would have for declining an experiment is if (a) the opportunity is too small and therefore a successful outcome is meaningless, or (b) the team doesn’t yet know how to measure progress.
1818
13/8/2021 2:35:16 am
“good ideas don’t come along only during the planning cycle. They hit you at any time of the year,”
1890
13/8/2021 2:41:20 am
This is why clarity of metrics is so important at the onset of an experiment.
1942
13/8/2021 2:46:11 am
The biggest concern people have about experiments is how to avoid harming customers in the process.
1959
13/8/2021 2:48:02 am
you can test that hypothesis easily by building a quick website and buying ads on Google—seeing if you can get people to bite. You don’t have to actually build the product, just the marketing website to see if the value proposition resonates.
1983
13/8/2021 2:50:02 am
“Success is stumbling from failure to failure with no loss of enthusiasm.”
2054
13/8/2021 2:57:00 am
**Autonomy, Mastery, and Purpose**
2055
13/8/2021 2:56:59 am
The most important
2056
13/8/2021 2:55:24 am
Daniel Pink argues that compensation isn’t necessarily what motivates people. Or
2056
13/8/2021 2:55:29 am
Daniel Pink argues that compensation isn’t necessarily what motivates people.
2056
13/8/2021 2:55:40 am
**Daniel Pink argues that compensation isn’t necessarily what motivates people. Or it does, but only up to a point.**
2058
13/8/2021 2:56:00 am
Once you meet the bar of fairness, employees focus on the real reasons for work: autonomy, mastery, and purpose.
2059
13/8/2021 2:56:12 am
**Autonomy means the ability to work independently and not be told what to do.**
2060
13/8/2021 2:56:30 am
**Mastery means the ability to get better at your craft over time.**
2060
13/8/2021 2:56:37 am
**Purpose involves the feeling that the work you do actually matters.**
2145
13/8/2021 3:05:08 am
I want to create amazing things and learn from other smart people.
2149
13/8/2021 3:05:45 am
young or otherwise, are always hoping to be pushed, to learn, and to grow. They want to get better at what they do, and to find mentors who will help them develop.
2222
13/8/2021 3:10:44 am
To be a good recruiter you need to present your version of the Hero’s Journey. What do we do here? What challenges are we facing? Why is our work important? Why should you care about your job? What’s at stake? Why will you be excited to come to work every day?
2241
13/8/2021 3:12:18 am
When you can be yet another cog in the machine, or a key member of a small but important team—many developers find the latter is a pretty compelling opportunity.
2259
13/8/2021 3:13:43 am
back to Daniel Pink, the best compensation plans are those where employees feel they’re compensated fairly, allowing them to move their attention from comp to the work.
2337
13/8/2021 3:18:58 am
An open, learning environment is one where the organization is receptive to not having all of the answers, is comfortable with uncertainty, and strives to get better every day.
2423
13/8/2021 3:26:50 am
“Our goal every day is to suck less than we did yesterday.”
2464
13/8/2021 3:30:49 am
The way you get there is repeatedly asking “Why?”
2464
13/8/2021 3:30:57 am
Nice
2846
13/8/2021 4:02:51 am
**Bikeshedding, therefore, is the tendency for nonexperts in charge to expend a lot of calories on unimportant details, because they lack the context to make the most important decisions.**
3009
13/8/2021 4:13:53 am
the greatest purpose of small, multidisciplinary teams and single-threaded leaders is to keep teams feeling close to customers, accountable for decisions, and knowing that their work directly translates into progress.
3091
13/8/2021 6:42:03 pm
values can be empty words on the wall, or they can be guiding principles used daily by employees to make countless decisions.
3092
13/8/2021 6:42:25 pm
What takes them off the wall and into practices is two things: memorability and mechanisms.
3209
13/8/2021 6:50:16 pm
strength.” Sometimes developers are reluctant to meet with customers, usually out of social awkwardness.
3210
13/8/2021 6:50:22 pm
Sometimes developers are reluctant to meet with customers, usually out of social awkwardness.
3309
13/8/2021 6:59:09 pm
Scrum: The Art of Doing Twice the Work in Half the Time,
3310
13/8/2021 6:59:17 pm
Read
3426
13/8/2021 7:19:04 pm
All you care about, as an outsider, is whether a story points metric gives the team an increasing degree of predictability and productivity.
3753
13/8/2021 8:13:02 pm
Operational Maturity Model (OMM). It consists of six categories of excellence: documentation, security, supportability, resiliency, testability, and privacy.
3886
14/8/2021 7:16:37 pm
Amazon also prefers speed and doesn’t obsess about duplication, according to Werner Vogels.
Jeff Lawson "Ask Your Developer" is a playbook on how to make a company can leverage the important role of developer and how to set and environment to make developer can thrive in helping building a great business. This is the first business book that I know which focusing on the role of developer in business.
Jeff started the book discussing on how digital economy revolution that is happening now has made software shifted from cost center into profit center, from back office to the face of company. With this shifts, developer is under spotlights and becomes a really important actor in the revolution.
Ask your developer are divided into three main parts:
- The importance of developers
- How to motivate developers
- Making developers successful
The ideas are presented with the context of Jeff experience in building Twillio. Twillio is Platform as a service (PaaS) company that provides API integration related to communications such as phone call or text messages.
These are some great ideas from the book:
- In deciding build and buy software:
- The only things companies should build themselves are the things that are core to their business.
- Anything that gives you differentiation with customers, you should build.
- Anything that is customer-facing, you should build.
- Involve developer directly in solving business problem. Share the problems directly and not specification document.
- The most important things for developer (after money 🙂): Autonomy, Mastery, and Purpose
- Autonomy means the ability to work independently and not be told what to do.
- Mastery means the ability to get better at your craft over time.
- Purpose involves the feeling that the work you do actually matters.
The book is a must read for founders and developers.
# Highlights
437
11/8/2021 11:25:19 pm
Bunq’s founder and CEO, Ali Niknam,
528
11/8/2021 11:31:55 pm
That’s another reason why big corporations are so reluctant to change and why they continue to lag behind startups—because the top brass has a “shame and blame” culture, and the people who run the tech group don’t want to take risks.
642
11/8/2021 11:39:57 pm
Its founder and CEO, Marc Benioff, interned as an assembly language programmer at Apple (translation: he was a hard-core coder) and after university joined Oracle, where he quickly became a legendary salesman.
749
11/8/2021 11:47:49 pm
So Amazon started ascribing a cost to using these services, even internally. Some people call this transfer pricing, but in fact it’s a system of doing two things: holding teams accountable for their costs, and deciding where to put more resources in budget cycles.
784
11/8/2021 11:50:11 pm
**The only things companies should build themselves are the things that are core to their business.**
786
11/8/2021 11:50:27 pm
**My rule of thumb is that for anything that gives you differentiation with customers, you should build.**
794
11/8/2021 11:51:03 pm
**anything that is customer-facing, you should build.**
817
11/8/2021 11:52:33 pm
In fact, people have theorized about the “one-person unicorn,” meaning a company that is valued at $1 billion or more but is run by one person—a developer whose app sits on top of all those commercial microservices.
951
12/8/2021 12:14:22 pm
I’ve always thought that the best way to learn something new was to commit yourself to “customers” and force yourself to learn.
1087
12/8/2021 12:24:49 pm
leaders. S3 was informally led by Al Vermeulen,
1087
12/8/2021 12:24:59 pm
Al Vermeulen, Amazon’s CTO.
1114
12/8/2021 12:27:45 pm
This is how innovation works: experimentation is the prerequisite to innovation. The more quickly and cheaply you can run experiments, the faster you’ll eventually find something that works. So I kept looking for ideas.
1185
12/8/2021 12:32:59 pm
I’ve learned that the key ingredient to unlocking innovation is cultural more than anything
1185
12/8/2021 12:33:10 pm
the key ingredient to unlocking innovation is cultural more than anything else, and that culture starts at the top.
1267
12/8/2021 12:38:36 pm
Joe Rogan, who launched a free podcast in 2009 and in 2020 inked a $100 million deal with Spotify;
1309
12/8/2021 1:18:53 am
When you think of software developers, instead of Urkel, Sheldon, or Dennis Nedry, think of Patrick McKenzie, Ryan Leslie, Leah Culver, and Chad Etzel.
1363
12/8/2021 1:23:15 am
**Share problems, not solutions with your developers.**
1381
12/8/2021 1:24:40 am
‘Scientists find problems, and engineers fix problems.’ That’s always been my outlook on software engineers. They’re problem solvers.
1535
12/8/2021 11:43:57 am
When developers actually care about their work, intrinsic motivation kicks in and unlocks new and even more creative ideas.
1536
12/8/2021 11:44:10 am
When a developer is merely reading a specification document, they become isolated from the people who will use the software.
1623
12/8/2021 11:50:37 am
increasing the GDP of the Internet,
1680
12/8/2021 11:53:17 am
bringing developers into the big problems you’re trying to solve, and leveraging their full brains.
1750
13/8/2021 2:30:04 am
The only reason I would have for declining an experiment is if (a) the opportunity is too small and therefore a successful outcome is meaningless, or (b) the team doesn’t yet know how to measure progress.
1818
13/8/2021 2:35:16 am
“good ideas don’t come along only during the planning cycle. They hit you at any time of the year,”
1890
13/8/2021 2:41:20 am
This is why clarity of metrics is so important at the onset of an experiment.
1942
13/8/2021 2:46:11 am
The biggest concern people have about experiments is how to avoid harming customers in the process.
1959
13/8/2021 2:48:02 am
you can test that hypothesis easily by building a quick website and buying ads on Google—seeing if you can get people to bite. You don’t have to actually build the product, just the marketing website to see if the value proposition resonates.
1983
13/8/2021 2:50:02 am
“Success is stumbling from failure to failure with no loss of enthusiasm.”
2054
13/8/2021 2:57:00 am
**Autonomy, Mastery, and Purpose**
2055
13/8/2021 2:56:59 am
The most important
2056
13/8/2021 2:55:24 am
Daniel Pink argues that compensation isn’t necessarily what motivates people. Or
2056
13/8/2021 2:55:29 am
Daniel Pink argues that compensation isn’t necessarily what motivates people.
2056
13/8/2021 2:55:40 am
**Daniel Pink argues that compensation isn’t necessarily what motivates people. Or it does, but only up to a point.**
2058
13/8/2021 2:56:00 am
Once you meet the bar of fairness, employees focus on the real reasons for work: autonomy, mastery, and purpose.
2059
13/8/2021 2:56:12 am
**Autonomy means the ability to work independently and not be told what to do.**
2060
13/8/2021 2:56:30 am
**Mastery means the ability to get better at your craft over time.**
2060
13/8/2021 2:56:37 am
**Purpose involves the feeling that the work you do actually matters.**
2145
13/8/2021 3:05:08 am
I want to create amazing things and learn from other smart people.
2149
13/8/2021 3:05:45 am
young or otherwise, are always hoping to be pushed, to learn, and to grow. They want to get better at what they do, and to find mentors who will help them develop.
2222
13/8/2021 3:10:44 am
To be a good recruiter you need to present your version of the Hero’s Journey. What do we do here? What challenges are we facing? Why is our work important? Why should you care about your job? What’s at stake? Why will you be excited to come to work every day?
2241
13/8/2021 3:12:18 am
When you can be yet another cog in the machine, or a key member of a small but important team—many developers find the latter is a pretty compelling opportunity.
2259
13/8/2021 3:13:43 am
back to Daniel Pink, the best compensation plans are those where employees feel they’re compensated fairly, allowing them to move their attention from comp to the work.
2337
13/8/2021 3:18:58 am
An open, learning environment is one where the organization is receptive to not having all of the answers, is comfortable with uncertainty, and strives to get better every day.
2423
13/8/2021 3:26:50 am
“Our goal every day is to suck less than we did yesterday.”
2464
13/8/2021 3:30:49 am
The way you get there is repeatedly asking “Why?”
2464
13/8/2021 3:30:57 am
Nice
2846
13/8/2021 4:02:51 am
**Bikeshedding, therefore, is the tendency for nonexperts in charge to expend a lot of calories on unimportant details, because they lack the context to make the most important decisions.**
3009
13/8/2021 4:13:53 am
the greatest purpose of small, multidisciplinary teams and single-threaded leaders is to keep teams feeling close to customers, accountable for decisions, and knowing that their work directly translates into progress.
3091
13/8/2021 6:42:03 pm
values can be empty words on the wall, or they can be guiding principles used daily by employees to make countless decisions.
3092
13/8/2021 6:42:25 pm
What takes them off the wall and into practices is two things: memorability and mechanisms.
3209
13/8/2021 6:50:16 pm
strength.” Sometimes developers are reluctant to meet with customers, usually out of social awkwardness.
3210
13/8/2021 6:50:22 pm
Sometimes developers are reluctant to meet with customers, usually out of social awkwardness.
3309
13/8/2021 6:59:09 pm
Scrum: The Art of Doing Twice the Work in Half the Time,
3310
13/8/2021 6:59:17 pm
Read
3426
13/8/2021 7:19:04 pm
All you care about, as an outsider, is whether a story points metric gives the team an increasing degree of predictability and productivity.
3753
13/8/2021 8:13:02 pm
Operational Maturity Model (OMM). It consists of six categories of excellence: documentation, security, supportability, resiliency, testability, and privacy.
3886
14/8/2021 7:16:37 pm
Amazon also prefers speed and doesn’t obsess about duplication, according to Werner Vogels.
January 17, 2022
Very good tips on boosting innovation by getting the most out of your developers
December 9, 2021
Yes, the book is written by the CEO of Twilio. Yes, there's a fair bit of direct and indirect marketing for their products and engineering organisation.
But this book is really great. It pulls together ideas from empowering teams, attracting and retaining creative talent, Working Backwards, the power of wearing the customer's shoes, and finally the value of investing in software infrastructure.
But this book is really great. It pulls together ideas from empowering teams, attracting and retaining creative talent, Working Backwards, the power of wearing the customer's shoes, and finally the value of investing in software infrastructure.
January 26, 2021
Every big corp depends on software to increase its productivity. This trend is not new : banks, insurances ... have been using a lot of software for more than 25 years. Yet, they are getting disrupted by new players on the field, who move extremely fast, and manage to acquire large client bases while keeping headcount small. So, why couldn't the incumbents do it ? This book will tell you.
Lawson provides a thorough analysis of the organizational structures which make startups so _fast_ and dangerous for incumbents. I imagine this will be useful for managers/execs in legacy corps and consultants. Among others, he cites :
- treating engineers as creatives, instead of Taylorism-like workers checking small-scoped tickets
- creating an organization which places clients at its center, for real.
- improving iteration speed through reorganization around small teams and microservices
- investing in tools for engineers, the same way it is done for HR and Sales
- improving tech infrastucture, which acts as a multiplier for tech productivity
There is much more, which is crafted around examples and edge cases, and made me node my head along.
He also has few interesting points for people already in "fast" tech, which may be missed by non-technical people but have incredible implications. One of them is around the commoditization of APIs. The future of software may be about building elementary blocks used to build more complex software : this is the author's business at Twilio for communication, Stipe for payment, and was already predicted by Hamming's The Art of Doing Science and Engineering.
A crucial difference compared to buying custom-made softwares from IBM, Capgemini, ... is that it enables companies to craft ONLY what makes their business special, and much better integrate with the rest of their software.
The book is a quick read, necessary for everyone in legacy companies and wanting to start one, heavily recommended for people interested in organizational systems.
Lawson provides a thorough analysis of the organizational structures which make startups so _fast_ and dangerous for incumbents. I imagine this will be useful for managers/execs in legacy corps and consultants. Among others, he cites :
- treating engineers as creatives, instead of Taylorism-like workers checking small-scoped tickets
- creating an organization which places clients at its center, for real.
- improving iteration speed through reorganization around small teams and microservices
- investing in tools for engineers, the same way it is done for HR and Sales
- improving tech infrastucture, which acts as a multiplier for tech productivity
There is much more, which is crafted around examples and edge cases, and made me node my head along.
He also has few interesting points for people already in "fast" tech, which may be missed by non-technical people but have incredible implications. One of them is around the commoditization of APIs. The future of software may be about building elementary blocks used to build more complex software : this is the author's business at Twilio for communication, Stipe for payment, and was already predicted by Hamming's The Art of Doing Science and Engineering.
A crucial difference compared to buying custom-made softwares from IBM, Capgemini, ... is that it enables companies to craft ONLY what makes their business special, and much better integrate with the rest of their software.
The book is a quick read, necessary for everyone in legacy companies and wanting to start one, heavily recommended for people interested in organizational systems.
June 30, 2022
The first part of the book provides the annotated / "anecdoted" context of software development history. I found it crisp and informative, yet not overly surprising or new. I really moved from liking to loving this book once Jeff gets into the nitty-gritty of how to build, nurture and unleash teams and with it digital companies. It covers much, yet feels right, tight, and supported by many actionable hints, examples and a philosophy that I've been treasuring for a while, and after this book, feel even better equipped to help nurture, live and build. Thanks!
Keywording
3 words on a billboard outside San Francisco. 3 out of Features, Deadline, Certainty, and Quality possible at a time, wiggle on Features. Ask Your Developer = mindset. Behave compassionately but prioritize ruthlessly. Benioff the SaaS launching coder. Beware of coordination complexity. Bezos' Brain Benders. Build up the deep bench (e.g. Amazon's Level 3 GMs) and learn by doing. Code hairball vs. microservices. Commonality: Understanding the problem. Customer Feel is the ultimate benchmark and multiplier. Developer rush from direct customer pat: an addiction you wanna nourish. Differentiation can't be bought, build it. Digital native vs outsourceable IT cost center. (Potential) Duplication of efforts crushes perfect synchronization any day. ESOP for everyone, äh, yup! Guardrails to set people free. Hamers hammered it in(g), UBS he does it again? Hospitality, not only Service. Identify with team, not function first. Instill Importance, Urgency, Focus. Invest in Infrastructure or be darned by FBATR. Kanban, Kannst Bannen. Keep coordination energy negligible, "talk more" ain't the game. Keep things immediate, small is beautiful. Learn to build. Opt-in to complexity. Permit failure, or fail. Person that writes the code, wears the pager. Pink-it! RAPID without V, otherwise victims. Platform, the force multiplier. Safe to be uncertain. Single-threaded leaders. Start with the press release. Tell hero journey to get great talents. Truth-seekers, not truth-holders. Write it down or it doesn't count.
Keywording
3 words on a billboard outside San Francisco. 3 out of Features, Deadline, Certainty, and Quality possible at a time, wiggle on Features. Ask Your Developer = mindset. Behave compassionately but prioritize ruthlessly. Benioff the SaaS launching coder. Beware of coordination complexity. Bezos' Brain Benders. Build up the deep bench (e.g. Amazon's Level 3 GMs) and learn by doing. Code hairball vs. microservices. Commonality: Understanding the problem. Customer Feel is the ultimate benchmark and multiplier. Developer rush from direct customer pat: an addiction you wanna nourish. Differentiation can't be bought, build it. Digital native vs outsourceable IT cost center. (Potential) Duplication of efforts crushes perfect synchronization any day. ESOP for everyone, äh, yup! Guardrails to set people free. Hamers hammered it in(g), UBS he does it again? Hospitality, not only Service. Identify with team, not function first. Instill Importance, Urgency, Focus. Invest in Infrastructure or be darned by FBATR. Kanban, Kannst Bannen. Keep coordination energy negligible, "talk more" ain't the game. Keep things immediate, small is beautiful. Learn to build. Opt-in to complexity. Permit failure, or fail. Person that writes the code, wears the pager. Pink-it! RAPID without V, otherwise victims. Platform, the force multiplier. Safe to be uncertain. Single-threaded leaders. Start with the press release. Tell hero journey to get great talents. Truth-seekers, not truth-holders. Write it down or it doesn't count.
April 25, 2021
Think small, not big. The personal computer killed the mainframe. The global internet routing tiny packets displaced the local network. And microservices called from everywhere (many from Twilio) have upended the monolith of coding in every software house. Want to know how this all happened? Ask Your Developer.
Jeff Lawson shares his hard won insights here in plain english that non-developers, managers, and business teams can easily use to chart the course ahead.
Working at Amazon, on Amazon Web Services (AWS) was a real world how to lesson and roadmap for Lawson, who cribbed meticulous notes and went on to found Twilio with similar small ambitions. Some of the key insights Jeff gleaned from Amazon are foremost: the value of microservices and open APIs upon which the world, not just your own teams, can build the future of the web, pizza, cabs, commerce, and unimaginably many things.
Twilio was built not by fast armies but by small teams working Amazon's 'two-pizza box' style, delivering small services, think AWS, running many parallel experiments to build an unmatched communications platform and unparalleled financial results. All this from thinking small, and focusing on the customer.
If you are involved in business, or tech, or pick up the phone, or booked an Uber, ordered pizza from Dominoes or surf the web there is no doubt that you have used many microservices from Twilio, Jeff, and team. You can thank them by reading this book and thinking doubly hard on how you think smaller still.
Few of us get to work inside Amazon or AWS, but all can grab this book and crib notes yourself on how to offer your small slice of pie for the world to mash-up into the mix that is our present and future.
Bonus: Jeff Lawson has signed the Giving Pledge to give back the majority of his life's winning to share his slice with others, still. Kudos for that Jeff.
Jeff Lawson shares his hard won insights here in plain english that non-developers, managers, and business teams can easily use to chart the course ahead.
Working at Amazon, on Amazon Web Services (AWS) was a real world how to lesson and roadmap for Lawson, who cribbed meticulous notes and went on to found Twilio with similar small ambitions. Some of the key insights Jeff gleaned from Amazon are foremost: the value of microservices and open APIs upon which the world, not just your own teams, can build the future of the web, pizza, cabs, commerce, and unimaginably many things.
Twilio was built not by fast armies but by small teams working Amazon's 'two-pizza box' style, delivering small services, think AWS, running many parallel experiments to build an unmatched communications platform and unparalleled financial results. All this from thinking small, and focusing on the customer.
If you are involved in business, or tech, or pick up the phone, or booked an Uber, ordered pizza from Dominoes or surf the web there is no doubt that you have used many microservices from Twilio, Jeff, and team. You can thank them by reading this book and thinking doubly hard on how you think smaller still.
Few of us get to work inside Amazon or AWS, but all can grab this book and crib notes yourself on how to offer your small slice of pie for the world to mash-up into the mix that is our present and future.
Bonus: Jeff Lawson has signed the Giving Pledge to give back the majority of his life's winning to share his slice with others, still. Kudos for that Jeff.
February 16, 2021
The book to hand to senior execs
I don’t know Jeff though full disclosure I do know Eric Ries who wrote the introduction to this book and I do know some of Twillio’s early investors and I’ve been a customer of theirs in the past at previous jobs (and I assume I will use them again at future companies).
I’ve been online a few years longer than the author and my career has some parallels (multiple startups, stints at larger companies) and while I haven’t (yet) founded a billion dollar corporation my advice to company executives as a part time CTO/COO is nearly identical to much of this book. In fact I am likely to buy copies of this book for future clients.
So most definitely keep asking your developers - and strive to build organizations and structures to empower them and to connect all parts of your company to customers.
I don’t know Jeff though full disclosure I do know Eric Ries who wrote the introduction to this book and I do know some of Twillio’s early investors and I’ve been a customer of theirs in the past at previous jobs (and I assume I will use them again at future companies).
I’ve been online a few years longer than the author and my career has some parallels (multiple startups, stints at larger companies) and while I haven’t (yet) founded a billion dollar corporation my advice to company executives as a part time CTO/COO is nearly identical to much of this book. In fact I am likely to buy copies of this book for future clients.
So most definitely keep asking your developers - and strive to build organizations and structures to empower them and to connect all parts of your company to customers.
November 21, 2020
Disappointed with it. Basically devs should use micro services instead of building when they can. Whole book is about how awesome this guy’s company is, not how they became awesome/what they did/how they lead their teams.
60 pages of the CEO gloating about how awesome he is.
60 pages of the CEO gloating about how awesome he is.
February 8, 2021
Approachable narrative of the third technical wave of tech with the API economy. Anyone in this space it is a must read.
Displaying 1 - 30 of 142 reviews