 All right. Hello there. Welcome to architecting Drupal companies that are built to last. I always like to make sure that folks are in the right room before I start a session. And there's a few sessions this hour that have similar titles. So to be very, very clear, this is not Drupal architecture's flexible content, nor is it building platforms globally with Docker and DevOps. So if you are looking for one of those sessions, you're in the wrong room. This is going to be a non-technical session. My name is George Domet. I'm the founder and CEO of Palantir.net, which is a full-service web design, development, and strategy firm based in Chicago. We specialize in open-source solutions and are very involved in the Drupal project and community. I'm on the Drupal Association Advisory Board. I serve on the Drupal Community Working Group, as well as the Drupal.org Content Working Group. And I was also the co-chair of DrupalCon Chicago in 2011. Today I'm going to talk a little bit about the evolution of the Drupal project and some of the ways that companies can learn to adapt and thrive in an ever-changing environment. We will also have time at the end for some Q&A. And I want to start off with a brief history of the world's tallest buildings and talk about some of the analogies we can draw to the evolution of web development in the CMS. For most of recorded human history, our largest structures were made simply by piling huge stones on top of each other. The Great Pyramid of Giza, also known as the Pyramid of Kufu, was built over a 10 to 20-year period, concluding about 2560 BCE. The Great Pyramid was built by thousands of laborers who were primarily compensated for their efforts in the form of bread and beer. For nearly 4,000 years it was the largest structure in the world at about 146 meters, or for the Americans in the audience, that's 481 feet. And as I look at that and think about it, it also seems very reminiscent of the way that we used to build websites in the pre-CMS era, right? There was a vision of what the end product needed to look like, and we just keep piling on more code and more markup until it was done. So the Great Pyramid was surpassed in height only in the 14th century by the Lincoln Cathedral in the East Midlands of the United Kingdom. At 160 meters, or 525 feet tall, it was reputedly the tallest building in the world from about the year 1300 until a central spire collapsed in 1549 and was not rebuilt. Now, cathedral construction in the Middle Ages was community-funded and supported effort, frequently taking decades or even centuries to complete. When building a cathedral, the general approach was to get something fully functional up first, usually the chancel, which is where the high altar sits and where the choir sings. So once this minimum viable product had been completed, you could then extend outward as time and money became available, all the while maintaining a working place of worship. And because these buildings were built in stages over long periods of time, they could also evolve during construction, and there was a fair amount of experimentation and innovation as a result. And to me, this is what building a website with a content management system like Drupal gets you, right? You can get a basic website up and running fairly quickly and then build on top of it and innovate over time without taking down your site or starting over from scratch. So this is a diagram from 1884 of the world's tallest buildings. And at the very top there, you can see the just completed Washington Monument in Washington, D.C. in the United States at 169 meters or about 555 feet. The Washington Monument is in fact the world's tallest stone structure even today. But what's interesting as I take a look at this diagram is that, you know, these pyramids, cathedrals and monuments that make up this list, they were massive and incredibly impressive. As you can see, they've got a tremendous diversity of shapes and sizes, but much of their height was not actually very functional. Once you get above about 200 feet or so, there's actually almost no usable space. It's mostly just domes or spires. So these structures are really cool and impressive, but fundamentally they're ornamental rather than functional in nature. They're designed as places of worship and monuments to kings, emperors and presidents. They're not the kind of places that you would live or work in every day. But all that was about to change. In 1884, which is the same year that the Washington Monument was completed, a Chicago architect named William LeBaron Jenny made a huge innovation with the home insurance building, which you see here. It was built using a load bearing structural steel frame that supported the entire weight of the walls instead of load bearing walls that carried the weight of the building. This was called the Chicago Skeleton Method, and for the first time you could have a very tall building with usable space all the way up to the top floor. So steel replaced stone architecturally, and the age of the skyscraper began. Its pinnacle was reached in 1931 with the construction of the Empire State Building, which is 102 stories tall and 381 meters, 1,250 feet in height. So these skyscrapers were a huge leap forward, but they were ultimately limited by both the cost of building them and the inflexibility of the Skeleton Method. You could pretty much just build a tower straight up. In fact, the Empire State Building remained the tallest building in the world for 40 years. And I think this is where we're at with Drupal 7. We've certainly scaled in terms of raw size and functionality of the sites that we can build, but we're also hitting the limits in terms of Drupal's cost-effectiveness, technical overhead, and flexibility. Drupal as a project, as we know, has recently had difficulty scaling to meet the needs of today's web. You know this if you were listening to Drew's keynote yesterday. It's often cheaper and easier to use a framework than it is to use Drupal. And while that's true for sites of all sizes, it's particularly true for some of the largest customers who often choose to create their own bespoke platforms. So in 1969, the architecture firms Skidmore, Owings, and Merrill were hired to create a building with 3 million square feet of office space for thousands of Chicago-based employees of the Sears Corporation. To meet this challenge, SOM's architect Bruce Graham and engineer Fazler Kahn designed an approach that essentially combined nine individual, what they called tubes, right, but were actually pretty much their own building. And they cluster these in a three-by-three matrix. So if you take a look, you can see all nine tubes rise up to the 50th floor of the building, which is basically right at that point where the skyline is in that picture. At the 50th floor, the northwest and southeast tubes end, and the remaining seven continue up. At the 66th floor, the northeast and the southwest tubes end, and then at the 90th floor, the northeast and south tubes end. So the remaining west and center tubes then continue all the way up to the 108th floor. The Sears Tower was completed in 1974 and reached a height of 1,729 feet, 527 meters. It was, by most standards, considered to be the world's tallest building until the completion of the Patronus Towers in Kuala Lumpur in 1998. Now, I know if there's any Canadians in the audience, they're probably going to want to point out that the CN Tower in Toronto is taller, and that's true. But because it doesn't have floors that extend continuously from the ground level, it's actually not considered a building by most experts. This is a matter of hot debate within the skyscraper classification community, so I did want to make sure to acknowledge that. The advantage of the bundle tube structural system is that it provided great economic efficiency because it required less steel, and it offered greater flexibility because buildings could take on more shapes. And I think this is what Drupal 8 promises to offer us with its object-oriented approach, configuration management, improved APIs, and native web services support. When you have this kind of flexibility, all sorts of things become possible. And this is the direction that Drupal needs to go in order to remain competitive with other platforms like WordPress, Type-03, Adobe Experience Manager, and Sitecore. The structural innovations that were introduced by the CN Tower four decades ago brought about a renaissance and skyscraper construction that continues to this day. So this is the Burj Khalifa in Dubai, which is not just the tallest skyscraper in the world today, but it's also the tallest structure ever built by mankind. It has 163 floors and has 829 meters, or 2,722 feet tall. Drupal answers the increasing call for skyscraper websites. It can and does already support some of the largest, most trafficked and complex sites on the planet, and with Drupal 8 will be even better equipped to do so. But just as building a building like the Sears Tower or the Burj Khalifa requires an entirely different model than building the Great Pyramid or a medieval cathedral, building large and complex websites also requires a different approach. So the greatest engineering project in human history was the Apollo program, which successfully put human beings on the moon barely eight years after the first manned spaceflight. This was a massive effort that cost over $200 billion in inflation-adjusted U.S. dollars, and at its peak employed 400,000 people and required the support of over 20,000 industrial firms and universities. And with so many different vendors working together toward a common goal, coordination was absolutely vital, especially when the most minor mistake could have devastating impacts. And in fact, in 1967, three astronauts, Gus Grissom, Ed White, and Roger Chaffee, were killed by a cabin fire that was caused by a one spark from an electrical short during a launch rehearsal for Apollo 1. In the wake of that tragedy, NASA made many operational changes that were designed to reduce the siloing of communications between different NASA centers as well as various contractors. Another key change was the creation of an orchestrated manned flight awareness program to ensure that every single one of the hundreds of thousands of people who were involved in the Apollo program in some way were fully motivated, committed, and invested in the safety of the astronauts whose very lives depended on their efforts. And in fact, 20 years later, as part of the Rogers Commission report following the loss of seven astronauts in the Challenger disaster, physicist Richard Feynman, who sat on that committee, also cited the lack of communication between NASA management and engineers as a key factor in underestimating the risks that are involved with every space shuttle launch. The way that we build websites has completely changed in the last few years with the rise of distributed version control systems like Git, which makes development a lot more collaborative than it used to be. It also means that communication becomes much more important. That's right, so that's one of the reasons that we capture business requirements in user story format. But even if you have a full set of user stories, it doesn't guarantee that something won't get lost in translation. Large web projects often have hundreds and hundreds of user stories and take many, many months to complete. Even if you have a dedicated team throughout the entire project, it's very easy for something to fall through the cracks or for regressions to occur. So at Palantir, we use behavior-driven development or BDD for our projects. Using a BDD framework like Behat, we can constantly test our code base against our user stories, which, when linked with a hosted repository like GitHub, enables continuous integration using services like Travis or Jenkins to ensure that no regressions occur as new code is merged in. All of this means that it's easier than ever before for large distributed teams of developers to build complex and sophisticated systems. But the best part is that it empowers individuals and enables everyone to share responsibility for the overall quality of the project. Being able to do this means that you need to trust and listen to your team and be open to constantly integrating new ideas into your process. You don't want to chase every shiny new thing that comes along, but you do want your team to be able to do more of the things that make them better and fewer of the things that don't. So many large and high-profile Drupal projects involve multiple vendors from around the world who are all working simultaneously to bring the project to life. On these kinds of projects, it's not just absolutely essential that everyone is on the same page from the start, but that they remain on the same page throughout the project and remain focused on the end goal. That's why having a strong project management practice, good DevOps and strong communication channels is absolutely vital because the success of the project depends not just on the success of one firm, but of all the companies working on it. So in his keynote yesterday, Dries talked a lot about the challenges facing the Drupal project and ecosystem. He pointed out that a lot of people were holding off on starting new projects until Drupal 8 was released, which meant that many Drupal shops were seeing a slowdown in business. This is the Osborn problem. In the current version, if they know that a new version is right around the corner. And while that's definitely valid, it's not the only challenge facing the Drupal business ecosystem. Up until fairly recently, Drupal services and in particular expert Drupal services commanded a high premium in the marketplace because there wasn't enough talent to meet demand. Many folks in the community very correctly saw this as a threat to the project, and over the past few years, there's been a significant effort made to address it. And one of the things that we've seen is that there's been a lot of new companies entering the Drupal market because it's been pretty easy to do so. While the Drupal ecosystem used to primarily consist of boutique firms, large consulting firms and systems integrators like Accenture, Deloitte, and Capgemini have now built up Drupal teams and formed relationships with offshore partners to provide capacity for their clients. Some smaller firms have merged with others to form larger agencies or been acquired by bigger players in the market. In addition, the overall quality of Drupal development overall has increased to the point where even the less experienced firms are very often good enough for many development projects, and customers see less value in paying more to hire a firm or a consultant with more expertise. At the same time, the rise of companies like Acquia, Pantheon, and others that provide managed hosting and support services means that there's a lot less risk than in the past when customers were more likely to own their own infrastructure. So this is a classic case of commoditization. The more similar that products or services tend to be from a buyer's point of view, the more likely it is that they'll go with the cheapest option. The result is that there's been a downward pressure in rates for Drupal services at the same time that we're dealing with decreased demand. What this means is that firms need to work harder to differentiate themselves from the competition. This might mean specializing in a certain type of project or a particular market sector. It might mean developing a unique product or service offering that gives you added value over your competition. I believe that the best way to differentiate yourself in a time of change is to never lose sight of the fact that you're not selling technology, you're selling solutions to people's business problems. Ken Rickard, who's our director of professional services, did a presentation yesterday, and he's got a great quote that he likes to use, which is realize that you do not have a technology problem. You might have a content problem, you might have a governance problem or a communication problem or some other kind of problem, but Drupal is just a tool that people use to help solve those problems. It's not the solution itself. Despite what the sales folks in marketing people will tell you, there's no magic bullet that's going to fix everything. So if your company can offer the expertise necessary to help customers understand, articulate, and solve their problems in a holistic way, you're far more likely to win that business than you are just by demonstrating your technical skills. You're selling outcomes, not ours. Technology changes all the time. If you're going to be successful in the long term, you need to root yourself in something that's more stable. So let's talk about how to do that. Sometime back, I came across an article from the early 1970s about my grandfather, who was also named George Domet. He was a Greek immigrant who spent more than 60 years running several candy stores, soda fountains, and restaurants in Chicago. While the Domets candy and restaurant businesses were sold decades ago, the brand survives to this day, and you can still buy Domets Turtles in many U.S. grocery and convenience stores. I never really got to know my grandfather because he died when I was about seven years old, but I've heard many of the stories about him that were passed down by my grandmother, my father, and other members of the family. And from those stories, I've gotten a glimpse into some of the principles and values that helped make the business that he ran be so successful for so long. Simple things, like commitment to good service, honesty, listening to other people's good ideas. And as I was thinking about those things, I started doing some research into the values held by family businesses, which include some of the oldest and most enduring companies in the world. The longest lasting company in recorded history was Kongo Gumi, a Japanese Buddhist temple builder that was founded in the year 578 and lasted until 2006. At the time that Kongo Gumi was founded, most of Europe was still in the middle of the Dark Ages, the Prophet Muhammad was just a child, and the Mayan Empire was at its peak in Central America. Renowned for the quality of their work, Kongo Gumi helped build many famous and historic Japanese buildings over the centuries. Even though the Buddhist temple construction and repair business is a fairly stable one, Kongo Gumi still had to contend with a lot of socio-political changes that took place in Japan over the company's 1,400-year history. And part of what helped was that the company had unusually flexible succession planning. Even though Kongo Gumi technically was in the same family for 40 generations, control didn't automatically go to the eldest son. It went to the person in the family who was deemed the most competent, even if that person was a distant relative or related by marriage. Kongo Gumi also built a reputation not just for quality, but also for its focus on customer service. The company built relationships with their customers that lasted for centuries just like their temples. But I think the biggest factor in Kongo Gumi's long-term success was probably its unwavering commitment to a set of core principles that were documented in the 18th century and included advice such as always use common sense, concentrate on your core business, ensure long-term stability for employees, maintain balance between work and family, listen to your customers and treat them with respect, always submit the cheapest and most honest estimates, and my favorite, drink only in moderation. These principles were used by succeeding generations to help guide Kongo Gumi into the 20th century. When the temple business started to decline and the company started branching out into private and commercial construction, Kongo Gumi didn't shy away from changes in technology. It was the first in Japan to combine traditional wooden construction with concrete, and they were also the first to use CAD software to design temples. And while business had declined in the early years of the 21st century, the company was still earning more than 67 million US dollars a year in revenue into the mid-2000s. What ultimately led to the demise of Kongo Gumi were the speculative investments that the company had made during the Japanese real estate bubble of the 1980s and early 90s. In the years that followed, Kongo Gumi became massively over-leveraged and was unable to service the more than $343 million in debt that it accumulated since the collapse of the bubble. In 2006, they ended up being absorbed by a larger construction firm. In the end, Kongo Gumi was no longer able to survive as an independent entity after 1,400 years in business, not because of economic upheaval or changes in technology, but because its leadership strayed from the company's core principles, stopped taking the long view and went for the quick cash. Principles are designed to help answer the question of how a company does things and what criteria they should use to make business decisions. Companies that want to be successful in the long run need to identify their core principles and stick to them, even when doing so means passing up potentially lucrative opportunities in the short term. Regardless of whether a business involves building Buddhist temples, making chocolate-covered pecans or building websites, a focus on sustainability overgrowth encourages companies to put customers and employees first instead of shareholders and investors. These kinds of companies are uniquely positioned to learn from their failures, build on success, and learn how to thrive in an ever-changing business landscape. Anybody in the audience recognize who this is? Show of hands? No one? Yes. Thank you. It's too bad Hey Rocker isn't here because he would definitely know who this is. This is Steve Albini. He's a legendary recording engineer and musician who's worked on seminal albums for the Pixies, Nirvana, PJ Harvey, The Breeders, as well as dozens and dozens of records for countless independent and punk rock bands. For the last 18 years, he's run a recording studio in Chicago called Electrical Audio. Now, Albini deals with a lot of pretty intense personalities in a business that's not particularly known for its stability, but he credits his business enduring success to following two core principles. I'm going to quote them here. One, except does it given that you're not going to be receiving any patronage or any assistance from the outside world make do with what you have at hand immediately and never expect that things are going to get better. You deal with what you actually have and not some aspiration for what you might someday have and not some expectation of what someday you will be given or earn. Two, you can't shut anybody out of your scene or your business or your social circle. So, if somebody comes to you and offers to help or comes to you and wants to participate, then you let them participate. Somebody offers you work. It's work that you can do with a clear conscience, then you do it. Essentially, whenever the phone rings, you answer it and you do, you work with them. And I love these principles because they're simple, honest, realistic, and they make it really clear that Albini is doing this work because it's something he cares about. He's not doing it because it's going to make him rich, but because it's going to allow him to keep doing good work. Again, as he says, I'm proud of the fact that our studio has survived a lot longer than a lot of studios that were more cutthroat. And that I as an engineer in the music scene is a very enjoyable tenure as a working engineer. And that a lot of people who try to exploit the scene more or try to take advantage of certain structural contractual tricks, people who try to take every advantage, a lot of those people disappeared. Now, I've been talking a lot about the positive aspects of running a business based on principles. But following principles alone doesn't necessarily mean that you'll have a healthy corporate culture. So, I'm sure that many of you have read the recent New York Times article about the brutal workplace conditions at Amazon, not just for the folks who work in their warehouses, but also for their white collar workforce as well. And one of the things that our article talked a lot about was the company's 14 leadership principles, which guide all aspects of employee behavior. And among other things, explicitly encourage employees to drive themselves and others to unreasonably high standards and to disagree with others in lieu of compromise for the sake of social cohesion. The result is a company that's grown to dominate the online retail sector and has fundamentally changed the way that we think about everything from e-books to cloud computing. That growth has come at a tremendous human cost, however, and in addition, the company still struggles to make a profit even after 20 years in business. Amazon has prioritized growth and market share above all else, including profitability and the well-being of their employees. While many look to Amazon as a positive example of how technology can be used to change people's lives, I think it's also worth asking whether the human cost involved is really worth it so that I can get a copy of Dancing with Cats delivered to my house with free today shipping. The lesson here is that it's important that your principles be rooted in values that serve your customers and employees. For example, Frugality is a shared value of both Amazon and Steve Albini's company, but in Albini's case, it means that everyone in the company makes do with what they have and shares equally in service of a common cause. In Amazon's case, it means that everyone is asked to accomplish more with less and that employee benefits and perks are sacrificed in service of building a company that it's made its founder, Jeff Bezos, the fifth richest person on earth with a net worth of over $40 billion. So there's a mantra that often gets repeated in business business are the ones that fail fast, fail cheap, and fail often. And while there's truth to that statement, I think it's real meaning often gets twisted into an excuse for bad business decisions. Tiffany Ferris, who's Palantir's other CEO has a print by, this is by Mike Monteiro, it's hanging in our office, it reads, let's make better mistakes tomorrow. And I think this actually better captures the true meaning of the fail fast philosophy. It's not the act of failure that's essential but rather having learned why something failed that's key. And Tiffany's blog about how trying to avoid mistakes only leads to failure and how learning from one's mistakes as well as one's successes leads to progress and innovation. And as we've grown our firm over the last almost 20 years now we've definitely made mistakes but rarely have we made the same one twice. And one of the most important lessons we've learned is the importance of continuing to evolve Palantir's structure to meet the needs of our people and our clients. When we were a much smaller company we pushed back against any kind of structure or hierarchy because to us they felt like stifling legacy relics of bloated corporate bureaucracies. And up to a certain point a completely flat organizational structure works. But for an organization to scale successfully people need to understand the role that they play within it. And as we've evolved over time we've come to understand that structure and hierarchy is not about bowing to corporate cultural norms. It's about having an established position a place where you see not only how you fit but how everyone fits together into the whole. And while we've certainly had our share of growth that alone has never been the driving goal. It's far more nuanced than that. We want Palantir to be large enough to be successful at the projects that we want to work on with the people that we want to work with both internally and externally. So one thing that happens a lot in the tech industry is the glorification of the start-up. Even companies that aren't start-ups run themselves like start-ups in the belief that it's the best way to remain innovative and relevant in a fast-paced and constantly changing environment. The reality is that it's not. We actually have decades of research going back to the 19th century that prove that an eight-hour work day and a 40-hour work week is the best way to keep your team productive, happy, healthy, and safe. Henry Ford actually reduced the number of hours that his employees worked per week. Not because he was a particularly caring individual but because he looked at the data and he realized that doing so would actually increase their productivity. You can achieve short-term gains by pushing teams beyond that. But those fall off rapidly to the point where any sustained period of crunch time actually results in poor quality work that takes longer to accomplish. And this is true not just for folks who engage in physical labor but for knowledge workers as well. So I have a friend from college who works for a large, well-known technology company in Silicon Valley. And she recently described her life to me as consisting almost entirely of eating, sleeping, and working out of her apartment. Some days she doesn't even get out of her pajamas. She told me I may as well be a zombie. There needs to be a wider understanding that people are not machines and that what we do outside of work makes us better than when we're at work. And for those folks who do work at startups, the sweat equity pays off for disproportionately few. 75% of startups fail. And for those that don't, there are relatively few who actually gain true financial independence. Those are just the folks whose stories we happen to hear a lot. But for most, it's a pressure cooker that requires long hours often without adequate reward and with very little job security. And the kicker is it doesn't even involve, it doesn't even result in increased innovation. When the original Macintosh was being developed, Steve Jobs bragged that his team was working 90-hour weeks to bring it to market on an incredibly aggressive timeline. So productivity experts have actually gone back and looked at it and estimated that if the team had worked half as many hours per week, the Macintosh could have actually launched as much as a year earlier. Of course, if that had happened, we wouldn't have ended up with that iconic 1984 TV commercial, but what do you know? So at the end of the day, it's about optimization, right? When I or my colleagues are working, it's not meant to matter. Our responsibility is to help both our clients and our colleagues be successful. And that's why we've set up, we're set up to support people who work best remotely, as well as those who benefit from working in an environment, office environment, and people who work both ways. We recognize that different people thrive in different environments at different times. We also recognize that sometimes people have major life events, and that sometimes work arrangements need to be more flexible than a standard 9-5 schedule. The consequence of pushing your team beyond their limits in pursuing a strategy of growth for growth's sake is that you'll end up with a much higher rate of employee turnover, which is also known as churn. Now, some churn is natural in any organization, but too much is bad because it introduces additional costs and inefficiencies. There's a lot of overhead associated with turnover, including not just costs of recruiting and replacing outgoing team members, but also the indirect costs associated with the loss of institutional knowledge as well as the impact on company culture. Likewise, companies that spend all their time hiring new people often have difficulty building a cohesive team in a positive culture. Whenever possible, you want to pursue a managed growth strategy that's designed to help retain quality talent and enable existing team members to help retain talent. One thing that we've actually found to be really successful at Palantir is our paid internship program, which has enabled us to bring people on board who already understand how the company works and appreciates what it has to offer because they've worked as an intern. And this approach certainly takes a lot more time and investment, but in our experience it's been far more successful in the long term than using recruiters or relying solely on job postings like the presentation portion here before we go into Q&A by talking about a construction project that was begun here in Barcelona in March 1882. A local bookseller had taken a trip to the Vatican and was inspired by that visit to build a church in Barcelona similar to the one at Loretto. They raised the money, they hired an architect, and they started building a Gothic Revival Church, which you can see here. A year later, the original architect was an Antoni Gaudi, who took a look at what had been done so far and decided he wanted to take things in a slightly different direction. So, Gaudi spent the rest of his life working on the Sagrada Familia, and after over 130 years of construction it's still at least a decade away from completion. Obviously, over that time a lot has changed, and a lot of decisions about the project have been made since Gaudi's death. In fact, in many cases we don't even know what Gaudi's intent was, because most of his plans and models for the church were destroyed in the 1930s during the Spanish Civil War. There's a dominant myth in business of the big man, right? Folks like Steve Jobs, Elon Musk, Jack Welch, who have made an indelible mark on the companies that they've led. And I definitely don't want to underplay the talents or skills of those individuals, but the reality is that they were so successful in large part, not just because of their vision and charisma, but because they were the right people in the right place, at the right time and they had the great fortune to be able to collaborate with other incredibly talented and skilled individuals. Gaudi was a visionary, but he was also a very practical man, and he knew that the Sagrada Familia project was so big and so ambitious that it wouldn't be completed before his death. So here's what he said. There is no reason or regret that I cannot finish the church. I will grow old but others will come after me. What must always be conserved is the spirit of the work, but its life has to depend on the generations that is handed down to and with whom it lives and is incarnated. And in the end, I think that's how we have to think about our businesses as well, right? They're not just about one person. They're collective expressions of the individuals who are part of them at any point in time. So thank you for listening today. You can follow me on Twitter at GDEMET. You can follow Palantir at at Palantir. Please do not forget to submit an evaluation of this session, particularly if you liked it. And so we definitely have time for some Q and A. So if anyone has any questions or anything, please feel free to come up to the mic and ask away. Thank you. Don't be shy. Someone's got to have a question or even a comment. I'm that good? I said the truth? I spoke everything? There we go. Thanks. Very interesting presentation. Thank you. My background is in big corporations so I can resonate with a lot of the things you're saying. I also worked in Silicon Valley for many years, so I understand a lot about that culture too. Right now, I'm at the other end of the spectrum running a very small company, i.e. just myself and another guy, and I think a lot of what you said is very applicable to where Drupal is and where you, your company and similar companies are. I wonder how you would see the challenge or what you would say to an individual like myself at the other end of the sky spectrum? Yeah, absolutely. That's really, really valid. It wasn't so long ago that I was there too. Right? I think certainly my advice for anyone who's got a very small company or is just starting out is that it absolutely is all about building relationships and making connections with people and establishing a body of work that you can then have in your portfolio and then you can use to get more and better projects as time goes on. Coming from your background, I'm sure you're leveraging as many of the connections that you already have as possible and that's a great way to get going. In terms of Drupal, I think there is even though not a lot of people are starting new Drupal 7 projects at this point, there are still a whole lot of people out there who have Drupal 7 websites that they've invested a lot in and they're going to continue to need folks who can provide support for those sites or help them extend those sites because Drupal 7 it's not going to magically disappear or go away when Drupal 8 comes out there's going to be tens and hundreds of thousands of people running Drupal 7 sites who are going to continue to need support for those sites for years to come and so that's actually not a bad place to be for a small boutique if you have the opportunity to get in and do Drupal 8 sites that's also a huge huge area of potential but as yet it's unrealized Drupal 7 is here now Thank you Thank you very much for an excellent presentation I would also like to focus a little bit on the size issue I mean I come from a really small company where only 8 people and I would like to ask you from your experience what are the milestones of growth that change company culture and how do you avoid imploding just because you can't handle growth I think you're probably at one of them right now is my guess from my experience it was like 7 or 8 was a milestone I think like 15 was one 20 is a huge one and then 30 is also a big one beyond that and then I think probably 45 to 50 just in terms of raw numbers of folks from my experience when we we were about 7 or 8 folks that was actually right around the time when we started working with Drupal and it was right around the time as well that we realized that we couldn't before that point kind of all of us in the company wore a lot of different hats right different things and it was around that size where we really started to differentiate into different roles within the company right so that was about the point where we you know like okay we're going to hire someone who's a project manager right we're going to have folks who are dedicated designers we're going to have you know a differentiation between a front end developer and an engineer right so you know that's really the point where if you're still trying to have everyone in the company wear all the different hats and do all the different things it can get pretty hairy so my advice at that point is definitely start thinking if you haven't already about forming more defined roles within your organization about who does what does it answer your question? Anyone else? Alrighty, well thank you all very much