#jeff-lawson
In the twenty-first century, every business is a digital business. #software
Only the delusion that there’s no connection between software and patient care prevents that from becoming the norm. #construction-of-reality
Ask Your Developer begins with why it’s so important to actually understand what well-crafted software can make possible. It’s that initial leap of imagination that allows leaders to understand the value of software developers. #imagination
Building a structure and methodology for ideas to flow not just down but up the hierarchy, as well as across different areas of the organization, is critical not only to survive but also to thrive. #conways-law #communication
At so many companies, developers are disconnected from the business problems they’re solving and the customers they’re serving. Perhaps by their own choosing, or perhaps because of the engineering and management processes the company has constructed, developers just write the code they’re asked to write. The cold, dispassionate process of software development common in some companies is a tragedy both for the business and the developers. I see it as a failure to fully realize the potential of this amazing talent. #potential
Building software is incredibly hard, and building a culture of digital innovation is even harder. #culture
I think there’s often a false divide between businesspeople and software developers. At many companies, there’s a disconnect between the way businesspeople think, and what they want to accomplish, and what the software developers in those companies think they’re supposed to do. But it’s always struck me that business folks and software developers often want the same things—to build awesome products that delight customers, are massively adopted, and make a lot of money. However, businesspeople and developers often speak different languages and have different working styles—and these differences can inhibit the business and the developers from effectively collaborating to achieve their goals. #linguistics #sociolinguistics
Company leaders who build industry-changing software products seem to 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. #professional-development #learning #growth
In industry after industry, digital native companies are using technology to bring a new kind of product to market, faster, cheaper, and with a better customer experience than the incumbents. #progress
It’s natural selection driven by customers, who pick the companies that serve them better in this digital era. #natural-selection #evolution
But if all the banks just bought the same bank software, they’d all be undifferentiated again. So ultimately, they have to listen to customers’ needs and answer those needs with software by learning and iterating quickly. #person-centered #product #user-experience
Companies that adapt to the new digital landscape will serve customers better, and will survive. Those that don’t will die. It may not be overnight, but it’s inevitable. It’s as simple as that. It doesn’t matter what business you’re in. Banks. Airlines. Automakers. Insurance companies. Real estate. Retailers. Health care. Sure, you also have to deliver a great product or service at a competitive price. But in every market, the company with the best software will eventually win.
Most companies have embraced cloud computing, but they struggle with how to become software-centric organizations. #growth #business
Bringing more and more of the world’s problems into the domain of software is exactly what technologists have been doing for the last seventy years.
The category of problems to which we can apply the software mindset is exploding.
The buttons in a Tesla don’t even have labels. That’s so everything can be treated as software and updated constantly as Tesla gets customer feedback.
I love how obvious the software mindset is on display in these kinds of hardware companies—you literally see how they remove every bit of glass and plastic imaginable, so that only the absolutely required physical interface to the world is left. #hardware #design
One of our customers said it incredibly well: with off-the-shelf software apps, you have to change your business to match the software—which is crazy! Really, you should change the software to build the business your customers need.
That mindset arises from the way many cultures respond to failure. The norm is that if you launch a big initiative and it fails (in any department, not just tech), it would certainly limit your career. In more agile cultures, failure isn’t punished. Instead, it’s a learning opportunity. The mindset of embracing risk and tolerating failure is a huge part of the software ethos. It’s also one of the biggest things that old companies avoid—even those with leaders who claim, as many do, that they want to become more like a startup. #failure #fear-of-failure #agile #learning #opportunity #risk
It’s not enough to just hire a bunch of new developers, or to change the way developers do their jobs. None of that will work unless you also change the culture around them. Otherwise, you’re just planting a new tree in barren soil. #gardening
These world-class software builders are everywhere. Companies need to find them and turn them loose. Make them feel like owners. #ownership #autonomy
The realization I had while working inside AWS was that the AWS platform would unleash a new generation of startups that would be so much faster and leaner than traditional companies as to seem almost like a new species. #evolution #nature
APIs are well-defined interfaces that enable code to talk to other bits of code. Once a team builds and exposes an API to others, it’s important that they teach other teams how to use it via documentation that’s accurate and up to date. So at Amazon, an internal culture of API documentation arose. One team could find another team’s API documentation and start using their services, often without even needing to talk. This enabled the teams to effectively work together, solving the coordination problem. #communication #coordination #collaboration #efficiency
you can’t buy differentiation. You can only build it.
by taking off-the-shelf building blocks wherever possible, you can put all of your energy toward your unique areas of differentiation.
As new commercial microservices emerge, it’s not uncommon to remove the homegrown pieces over time and replace them with commercial alternatives. That’s because those commercial services are getting massive investment by vendors and getting better every day, whereas the home-built versions often stagnate over time.
Exactly when competition is growing more fierce is when companies must focus all of their internal development effort on the differentiating parts of the business. #strategy
Developers are usually the first to know what’s new and interesting in this digital supply chain.
My hope in writing this book is to bring these perspectives together—giving developers, managers, and executives a common language to improve their collaboration. #communication
I learned that even if you thoroughly messed it up, you could always fix it. And that, in many ways, is the essence of building. #learning
As a developer, you need deep concentration to hold the entire system in your head. People call it flow—that state where your mind is enveloped in a problem and you get an incredible amount of work done. Diving into a codebase, remembering how a particular part of the code worked well enough to make changes, takes incredible concentration. #flow #concentration
We were inventing the future—that’s the feeling you want your technical talent to feel. #future
company culture—the things you do as leaders that create the environment for great people to do their best work. #culture
This is how innovation works: experimentation is the prerequisite to innovation. #experimentation #innovation
The more quickly and cheaply you can run experiments, the faster you’ll eventually find something that works.
We take for granted all those wires we’ve wrapped the planet in, and now we have the luxury of thinking about what we build on top of that in software, with innovation happening in days or weeks, not months or years. #abstraction #technology
the key to getting businesspeople and developers to work well together is for the businesspeople to share problems, not solutions. #problemsolving
Like most people, developers like to win, too, but the game is different.
If you create an environment that lets developers scratch their itch, they’ll amaze you with what they can build.
There has never been a better time to be a software developer. The only limit is your imagination.
Writing software is more similar to making music or writing a book than it is to doing math or science. #art
Casual observers of innovation often overlook the thing that matters most, which is that developers are given responsibility and freedom. Not just freedom in working hours or what to wear, but freedom in terms of creativity. #freedom
Finding the shortest technical path in context is what engineers do for a living. #engineering
Great product managers are not a layer between customer needs and developers. In fact, they actually remove layers, eliminate preconceived solutions and erroneous presumptions, and streamline communications. Great product managers don’t abstract the developer from the customer needs; instead, they facilitate understanding of customer problems. The more layers there are between people who use a product and people who create the product, the worse things get. #product
Imagine if all business leaders used the same tactic inside their companies. Define the hairiest, scariest problems that a business faces, and do a “Call for Solutions” inside the company. Not every solution will be correct or worth pursuing, but by framing the big problems, you give developers the opportunity to think about the same things you are.
For better or worse, we all fall in love with our own ideas. #self-awareness
While Ping-Pong tables and tricycles are nice, I’m convinced the key to building a world-class engineering culture is bringing developers into the big problems you’re trying to solve, and leveraging their full brains.
Eric described experiments as planting seeds in the ground. You don’t necessarily know which ones, if any, will grow into giant trees. But you do know one thing: if you don’t plant any seeds, you won’t get any trees. #gardening
Writing it down, reminding people of the experiment’s purpose, and updating them on the progress is a great way to keep the experimental mindset alive and supported.
Mother Nature doesn’t weep or get embarrassed about all the millions of mutations that fail. She just keeps spinning them out. #nature
the thing that kills an entrepreneurial, experimental culture is when people get punished for running an experiment that proves a hypothesis false. (Note that I don’t call this “failing.”)
But one thing you might have gleaned from reading about Patrick McKenzie, Ryan Leslie, Leah Culver, and Chad Etzel is that the engineering mindset is often predisposed to (a) having strong opinions and (b) not keeping those opinions to themselves. To engineers, facts matter. I just think of it this way: engineers hate bullshit.
Don’t Love Failure, but Tolerate the Process
But it’s not the failure that’s celebrated, it’s the deep learnings that advance the mission. Failure is merely accepted as a natural consequence of the learning. When people talk about accepting failure, they’re talking about accepting the journey of discovery. #discovery
Notice above, when I talked about running experiments, it’s not about success or failure, it’s about accelerated learning.
So I believe that experimentation is not likely to hurt customer relationships. Rather, it’s the lack of experimentation that is likely to do more lasting harm.
In business, there’s often an expectation of a 100 percent success rate—and therein lies the fear for people to experiment. Breaking through that fear is key to successful innovation.
In the coming decade, the winners will be companies that build the best software—which really means, the companies with the best software developers.
Managing to retain them might be even more challenging. If your organization is dysfunctional, developers won’t sit around hoping that things will get better. They’ll bounce.
Once you meet the bar of fairness, employees focus on the real reasons for work: autonomy, mastery, and purpose. I believe this is especially true for developers.
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.
By empowering developers, you are trusting them to do their jobs and giving them tools, but you also instate some guardrails and rules. This is more realistic than full autonomy, especially for an organization at scale.
autonomy actually has its basis in rules. Without guardrails, people won’t know how to make decisions, and leaders will tend to second-guess them constantly. By creating rules, you paradoxically set people free—in the space between guardrails. #paradox
the importance of having “TQ at the table.”
Crafting public policy without involving technologists “is like trying to solve a legal problem without having a lawyer in the room.” #multidisciplinary-teams
Those two factors—create amazing things and learn from other smart people—are basically what all of us look for from our work. #meaningfulness #work
Computer science majors leave university with a degree but still have a lot to learn about how to ship production-level commercial code.
It’s easy for executives to exclaim “we’re on a path to digital transformation” because it sounds good, but to really embark on this journey, leadership has to be invested in the process and, more important, the people who will make it a reality.
“I’m finding there are a lot of very interesting challenges in every large corporation,” Werner Vogels says.
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? #recruitment
Most companies, even in our backyard, pay a bonus tied to weird corporate objectives. One kind is tied to company-wide objectives like revenue or profitability, the idea being that the whole company bands together to achieve these goals. The problem is that in reality no individual employee has the kind of impact to make or break these goals. So their compensation, which they will focus on a lot, is not tied to their job. It’s essentially random. Another problem is that you might have done a great job, but those idiots over in that other department didn’t do theirs and now nobody gets their bonus. What a rip-off! #money
Sometimes it takes so long to set the MBOs that by the time they’re set, they’re irrelevant or wrong. Then employees are focused on achieving the goals versus doing what’s right. #goals
You don’t want employees focused on bonuses. You want them focused on customers. You want creative energy. #focus
The best way to find out why talent is or isn’t attracted to your company is to . . . Ask Your Developers. Seriously. Ask your existing talent what’s working at the company, and what’s not. Ask developers who’ve been around what they love and what they hate about the company. How often do they think about looking for new roles, and what are they feeling when they think that? Last time they turned down a recruiter, what was going through their head? When you’re interviewing prospects, ask what they’re looking to accomplish and learn in their next role. #feedback
creating a world-class engineering culture is about building a system in which a large number of developers, product managers, and executives can have repeated successes building software. #culture
experimentation, which is a method of making progress toward a business innovation—but it’s really a process of learning. The faster you can learn, the better you’ll be. That mentality isn’t just about the things you need to learn—for example, what do our customers need?—but it also involves learning how to learn.
That process of learning to learn is one that every child goes through, starting in kindergarten. Yet once we graduate and enter the workforce, we seem to forget about all that. The process of “learning to learn” gets lost. We create rigid, unforgiving cultures that punish people who make mistakes. That approach might have worked in some bygone era—though I have my doubts. But it certainly does not work in today’s economy, where companies are locked in a Darwinian battle for survival in a world where the rules keep changing. Survival means being lean, nimble, fast, and constantly able to adapt. #education #survival
I’ve always liked what Andy Grove, the legendary CEO of Intel, wrote in High Output Management: When someone graduates from college with a technical education, at that time and for the next several years, that young person will be fully up-to-date in the technology of the time. Hence, he possesses a good deal of knowledge-based power in the organization that hired him. If he does well, he will be promoted to higher and higher positions, and as the years pass, his position power will grow but his intimate familiarity with current technology will fade. #power #knowledge
A big difference between an open, learning environment at work and the one we experienced in elementary school is that in school, the teacher knows the answers but shows students how to do the work to arrive at the answer on their own. In business, especially when you’re working on the cutting edge of technology, you’re not looking for an answer that someone else already knows. The business and its employees must find answers to questions that have not been asked before. But an open, learning environment provides the way to find those elusive answers. #teaching #pursuit-of-knowledge
Constructive criticism isn’t about tearing people down; it’s about helping them get better. It’s actually a form of respect. And it’s how people learn. #criticism-and-standards #feedback
When things go wrong, it’s either a time to blame, or a time to learn. #choice #blame-and-punishment
The true root cause is rarely technical in nature—it’s organizational.
You can’t learn to swim by watching videos and listening to lectures. You learn by getting into the pool.
there’s an assumption that competence in one field (engineering, sales, finance, etc.) transfers to competence in another field: being a GM. Sometimes that’s right, but too often it’s not. There’s even a term for it: the Peter Principle. It’s the idea that people rise to the level of their incompetence.
I’m always in awe of bootcamp grads because they took an incredibly difficult path to coding, building up the activation energy to change careers, often taking a leave from their paying jobs to retrain and re-skill. When we look at resumes, it’s common to measure a candidate’s position in their career: did they attend a top-notch school, did they work at prestigious companies prior, and so on. These are measures of position, but they don’t measure distance traveled.
when you account for how far a candidate has come in life as a measure of future potential, bootcamp grads rank highly on my list.
Government has historically been the bastion of big projects, big politics, and big blame.
Whether you’re in favor of small government or big government, we can probably all agree that most governments aren’t exactly known as innovators. Why? What happens when something goes wrong in government? Instead of quickly learning and iterating, or using it as a learning opportunity, the participants are hauled before Congress and grilled on national television. It’s the World Series of grandstanding. What do you think that does to organizational morale and risk-taking? #risk
Coordinating a 10-person team requires 45 relations between people, but coordinating a 100-person team results in nearly 5,000 relationships, and coordinating a 1,000-person company requires nearly 500,000 relationships to work. Amazon at 75,000 people in 2012 could have necessitated 2.8 billion relationships, making it 500,000 times as confusing and soul-crushing to navigate as the 100-person company it was at the start.
When you hold the whole picture in your heads and you work together every day, you can make progress incredibly fast. That’s the power of a small team—there are no proxies; you’re just directly solving customer problems with your code. #mental-models
For a team to develop the intrinsic drive of a startup, they need organizing principles that articulate their purpose. #mission
Once you have a customer defined, then you define a mission. This isn’t a marketing exercise, as company mission statements might become. Rather, this is a core purpose that the team themselves can agree upon and align around. #purpose
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. #bikeshedding
Taken to its logical conclusion, teams can choose the “product” of an internal team, or even choose to pick a vendor outside the company who provides the same service, perhaps at a better price, or with a better set of features or better service. When everybody has great interfaces, it allows teams to pick the best tool for the job and forces teams to up their game to “win” the business of internal customers. #product #interdependence #interfaces
I believe the goal isn’t better collaboration; it’s actually less collaboration. Great companies don’t say: “I need better customer support.” They say: “We should reduce the need for customers to contact customer support.”
Sure, we’ve got NPS surveys to tell us the cumulative effect of our actions on customers. But let’s be honest, customers who take the time to participate in a survey are mostly those who’ve developed strong feelings one way or the other about us, not representative of the typical customer. And surveys are strongly influenced by a customer’s last interaction, good or bad. It’s a point in time, but it really doesn’t tell us if we’ve created an organization that routinely internalizes and prioritizes customer problems to be solved over politics and organizational charts. #metrics #data #data-information-knowledge
In my experience, values can be empty words on the wall, or they can be guiding principles used daily by employees to make countless decisions. What takes them off the wall and into practices is two things: memorability and mechanisms. If they’re memorable, then employees are more likely to remember them, refer back to them, and want to use them in daily interactions.
I don’t ascribe to the idea that every customer idea should be built. Nor do customers even always know what they want. However, customers are very good at expressing their problems. #problemsolving
Sometimes, hard things take time. #time
A good platform will radically slash the time it takes for developers to get new code into production, letting fewer developers produce more code in less time. #platforms