Richard Seroter's Architecture Musings

Category: General

  • 2014 in Review: Reading and Writing Highlights

    I enjoyed 2014 and spent much of the year learning new things and building up an exceptional Product team at CenturyLink. Additionally, I spoke at events in Seattle, London, Houston, Ghent, Utrecht, and Oslo, delivered Pluralsight courses about Personal Productivity and DevOps, and tech-reviewed a book about SIgnalR. Below are some of the writing projects I enjoyed most this year, and a list of the best books I read this year.

    Favorite Blogs and Articles

    After seven years, I still look forward to adding pieces to this blog, in addition to writing for InfoQ, my company’s blog, and a few other available outlets.

    • [My Blog] 8 Characteristics of our DevOps Organization. This was by far the most popular blog post that I wrote this year. Apparently it struck a chord.
    • [Forbes] Get Ready For Hybrid Cloud. This Forbes piece kicked off a series of posts about Hybrid Cloud and practical advice for those planning these deployments.
    • [CTL Blog] Recognizing the Challenges of Hybrid Cloud: Part I, Part II, Part III, Part IV. In this four-part series, I looked at all sorts of hybrid cloud challenges (e.g. security, data integration, system management, skillset) and proven solutions for each.
    • [InfoQ] I ran a program about cloud management at scale, and really enjoyed conducting this interview with three very smart folks.
    • [My Blog] Richard’s Top 10 Rules for Meeting Organizers. The free-wheeling startup days are over for me, but I’ve kept that mindset even as I work for a much larger company now. Meetings are a big part of most company cultures, but your APPROACH to them is what determines whether meetings are soul-sucking endeavors, or super-useful exercises.
    • [My Blog] Integrating Microsoft Azure BizTalk Services with Salesforce.com. I don’t know the real future of BizTalk Services, but that didn’t prevent me from taking it for a spin. Here, I show how to call a Salesforce.com endpoint from a BizTalk Services process.
    • [My Blog] Using SnapLogic to Link (Cloud) Apps. Cloud-based integration continues to gain attention, and SnapLogic is doing some pretty cool stuff. I played around with their toolset a bit, and wrote up this summary.
    • [My Blog] Call your CRM Platform! Using an ASP.NET Web API to Link Twilio and Salesforce.com. Twilio is pretty awesome, so I take any chance I can to bake it into a demo. For a Salesforce-sponsored webinar, I built up a demo that injected voice interactions into a business flow.
    • [My Blog] DevOps, Cloud, and the Lean “Wheel of Waste.” I’ve admittedly spent more time this year thinking about organizational structures and business success, so this post (and others) reflect that a bit. Here, I look at all the various “wastes” that exist in a process, and how cloud computing can help address them.
    • [My Blog] Comparing Cloud Provisioning, Scaling, Management. I love hands-on demos. In these three posts, I created resources in five leading clouds and tried out all sorts of things.
    • [My Blog] Data Stream Processing with Amazon Kinesis and .NET Applications. There are so many cool stream-processing technologies out today! Microsoft shipped the Event Hubs over the summer, and AWS launched Kinesis a half-year before that. In this post, I took a look at Kinesis and got a sample app up and running.
    • [CTL Blog] Our First 140 Days as CenturyLink Cloud. This was my opportunity to reflect on our company progress six months after being acquired by CenturyLink.

    Favorite Books

    Of the couple dozen books that I read this year, these stood out the most.

    • Competing Against Time: How Time-Based Competition is Shaping Global Markets. This book may be twenty five years old, but it’s still pretty awesome. The author’s thesis is that “providing the most value for the lowest cost in the least amount of time is the new pattern for corporate success.” The book focuses on how time is a competitive advantage that improves productivity and responsiveness. Feels as true today as it was in 1990.
    • How to Fail at Almost Everything and Still Win Big. Love him or hate him (I happen to love him), Dilbert-creator Scott Adams is someone who challenges convention. In this enjoyable read, Adams delightfully recounts his many failures and his idea that “one should have a system instead of a goal.” Lots of interesting advice that will make you think, even if you disagree.
    • Start With Why: How Great Leaders Inspire Everyone to Take Action. The author states that “people don’t buy WHAT you do, they buy WHY you do it.” He then proceeds to explain how companies fail to motivate staff and engage customers by focusing on the wrong things. The best leaders, in Sinek’s view, have a clear sense of “why,” and motivate customers and employees alike. Good read and useful insight for existing and aspiring leaders.
    • The Practice of Cloud System Administration: Designing and Operation Large Distributed Systems, Volume 2. If you are doing ANYTHING related to distributed systems today, you really need to read this book. I reviewed it for InfoQ (and interviewed the authors), and found it to be an extremely easy to follow, practical book that covers a wide range of best practices for building and maintaining complex systems.
    • Creativity, Inc: Overcoming the Unseen Forces that Stand in the Way of True Inspiration. Probably the best “DevOps” book that I read all year, even though it has nothing to do with technology. This story from the founder of Pixar is fantastic. His thesis is that “there are many blocks to creativity, but there are active steps we can take to protect the creative process.” There’s some great insight into Pixar’s founding, and some excellent lessons about cross-functional teams, eliminating waste, and empowering employees.
    • The Art of War. A classic strategy book that I hadn’t read before. It’s a straightforward – but thoughtful – guide to military strategy that relates directly to modern business strategy.
    • Service Innovation: How to Go from Customer Needs to Breakthrough Services. What does it actually mean to bring innovation to a service? This book looks at customer-centric ways to identify unmet needs and deliver outcomes that the customer would consider a success. Very helpful perspective for those delivering any type of service to a (internal or external) customer base.
    • The Assist: Hoops, Hope, and the Game of Their Lives. Phenomenal story about a basketball coach who was all-consumed with ensuring that his underprivileged student-athletes found success on and off the court.
    • The Box: How Shipping Containers Made the World Smaller and the World Economy Bigger. I can’t tell you how many times my wife asked me “why are you reading a book about shipping containers?” I loved this book. It looks at how a “simple” innovation like a shipping container fundamentally changed the world’s economy. It’s a well-written historical account with lessons on disruption that apply today.
    • Mark Twain: A Life. This was a long, detailed book for someone with a long, adventurous life. A fascinating account of this period, the book recounts Twain’s colorful rise to global renown as a leading literary voice of America.
    • The Goal: A Process of Ongoing Improvement. The excellent DevOps book “The Phoenix Project” owes a lot to this book. The Goal tells a fictitious tale of a manufacturing plant manager who faces higher expenses and long cycle times. The hero discovers new ways to optimize an entire system by digging into bottlenecks, capacity management, batch sizing, quality, and much more. It’s a fun read with tons of lessons for software practitioners who face similar challenges, and can apply similar solutions.
    • Scaling Up Excellence: Getting to More Without Settling for Less. Spreading a culture of excellence to more people in more places requires hard work, relentless focus, a shared mindset, and amazing discipline. This book is full of case studies and guidance for successful (and unsuccessful!) scaling.
    • Jim Henson: The Biography. An outstanding, meticulously-detailed biography of one of the most talented and creative individuals of the last century. Great insight into team-building, quiet leadership, and taking risks.

    A heartfelt thanks to the 125,000+ visitors (and 207,000+ page views!) this year to the blog. It’s always a pleasure to meet many of you in real life, or in other virtual forums like Twitter. Here’s to the year ahead, and more opportunities to be inspired by technology and the the people around us.

  • Richard’s Top 10 Rules for Meeting Organizers

    Meetings are a necessary evil. Sometimes, you simply have to get a bunch of people together at one time in order to resolve a problem or share information. While Tier 3 was a very collaborative environment where there were very few meetings and information flowed freely, our new parent company (CenturyLink) has 50,000 people spread around the globe who need information that I have. So in any given week, I now have 40+ meetings on my calendar. Good times. Fortunately my new colleagues are a great bunch, but they occasionally fall into same bad meeting habits that I’ve experienced throughout my career.

    Very few people LIKE meetings, so how can organizers make them less painful? Here are my top 10 pieces of advice (in no particular order):

    1. Have a purpose to the meeting, and state it up front. It seems obvious, but I’ve been in plenty of meetings in my career where it seemed like the organizer just wanted to get people together and talk generally about things. I hate those. Stop doing that. Instead, have a clear, succinct purpose to what the meeting is about, and reiterate it when the meeting starts.
    2. Provide an agenda. Failing to send an agenda to meeting participants should result in meeting privileges being taken away from an organizer. What are we trying to accomplish? What are the expected outcomes? I’ve learned to reject meeting invites with an empty description, and it feels GLORIOUS. Conversely, I quickly accept a meeting invite with a clear purpose and agenda.
    3. Give at least 1 day of lead time. I find it amusing when I get meeting invites for a meeting that’s already under way, or that’s starting momentarily. That assumes that (potential) participants are sitting around waiting for spontaneous meeting requests that are immediately the most important thing in the world. In reality, that is only the case 1% of the time. Try and schedule meetings as far ahead as possible so that people can make adjustments to their calendar as needed.
    4. Always have a decision-maker present. Is there anything rougher than sitting through a 1 hour meeting and then realizing that no one in the room has the authority to do anything? Ugh. Unless the meeting is purely for information sharing, there should ALWAYS be people in the room who can take action.
    5. Only invite people who will actively contribute. It’s rare that a 10+ person meeting yields value for all those participants. Don’t invite the whole world and hope that a few key folks accept. Don’t invite more than one person who can answer the question. The only people who should be in the meeting are the ones who make decisions or those that have information that contribute to a decision.
    6. Do not cancel a meeting after it’s scheduled start time. Nothing’s more fun than sitting on hold waiting for a meeting to start, and then getting a cancellation notice. Plenty of people arrange parts of their days around certain meetings, so last-second cancellations are infuriating. If you’re a meeting organizer and you are pretty sure that a meeting will be moved/cancelled, send out a notice as soon as possible! Your participants will thank you.
    7. Start meetings on time. I’ll typically give an organizer 5-8 minutes to start a meeting. If I’m still waiting after that, then the meeting really isn’t that important.
    8. Schedule the least amount of time possible. It’s demoralizing to see 2-5 hour meetings on your calendar. Especially when they are for “working sessions” that may not need the whole time slot. We all know the rule that people fill up the time given, so as a general rule, provide as little time as possible. Be focused! When organizing any meeting, start with a 30 minute duration and ask yourself why it has to be longer than that.
    9. Prep the presenters with background material. I enjoy meetings where I hear “… and now Richard will walk through some important data points” and I’m caught by surprise. This is where an agenda can help, but make sure that presenters in your meeting know EXACTLY what you expect of them, who is attending, and any context about why the meeting is occurring.
    10. End every meeting with clear action items. Nothing deflates a good meeting like an vague finish. Summarize what needs to be done, and assign responsibility. Even in “information sharing” meetings you can have action items like “read more about it here!”

    Any other tips you have to help organizers conduct efficient, impactful meetings?

  • How Do I Get Things Done? New Pluralsight Course Reveals All My Secrets

    Back in August when I released a Pluralsight course on Optimizing Systems on AWS, the most frequent question I heard had nothing to do with AWS or the cloud. Instead, it was the familiar “how do you do so much stuff?” Various suggestions have been offered: robot twin, outsourcing to South America, zero sleep. Alas, the truth is less sensational. I’ve learned over the years (from experience, studying, and watching others) to be ruthless about efficiency and always take a strategic viewpoint on new opportunities. During the past few months I’ve jotted down all my techniques – as well as those used by a host of my fellow Pluralsight authors – and put them all into a single, 1 hour Pluralsight course that was released today.

    Productivity Tips for the Busy Tech Professional is a collection of 17 actionable tips for getting control over your busy schedule and spending more of your time on the things you enjoy. The course is broken up into three short modules:

    • Setting the Foundation. A handful of tips that will shape how you approach your activities.
    • Establishing a Frame of Mind. Tips for better decision making and prioritization.
    • Managing Time Effectively. Batch of tips for the day-to-day activities that will help you make better use of your available time.

    No theoretical stuff here. It’s all (hopefully) practical advice that you can use RIGHT NOW to get more done while keeping your work/life balance under control. Now, obviously everyone is different and for some, these tips won’t make a difference or you might completely disagree with them. That’s cool with me, as I’m just hoping to inspire change (large or small) that helps us all become happier and more fulfilled.

    So watch this course on your lunch break, and let me know what you think! Something you agree/disagree with? Have your own tips to share? I’d really love to hear it.

  • Favorite Books and Blog Posts of 2013

    The year is nearly up, and it’s been a good one. 30+ posts on the blog, job changes, 4 new Pluralsight courses, twice-monthly InfoQ.com contributions, graduation with a Masters Degree in Engineering, and speaking engagements around the world (Amsterdam, Gothenburg, New Orleans, San Francisco, London, and Chicago). Here’s a quick recap of my favorite blogs posts (from here, or other places that I write), and some of the best books that I read this year.

    Blog Posts

    While this was one of my quieter years on the blog, I probably wrote more than ever before thanks to the variety of places that I publish things. Here were some of my favorites:

    Books

    I read a few dozen books this year, and these were the ones that stood out for being informative, interesting, and inspirational.

    Once again, thanks to all of you for continuing to read my work and inspiring me to keep it up!

  • 8 Things I Learned From the Tier 3 Hack House

    In September, my employer Tier 3 rented a house in St. George, Utah so that the Engineering team could cohabitate and collaborate.2013.09.30hackhouse The house could accommodate 25 people, and we had anywhere from 8-12 folks there on a given week. This was the first time we’ve done this, and the concept seems to be gaining momentum in the industry.

    I joined our rockstar team in Utah for one of the three weeks, and learned a few things that may help others who are planning these sorts of exercises.

    1. Location matters. Why were we in a giant house located in Utah? I actually have no idea. Ask my boss. Our team is almost entirely based on Bellevue, WA. But this location actually served a few purposes. First, the huge house made it possible for us all to live and work in the same place. Doing this at a hotel or set of bungalows wouldn’t have had the same effect. Second, being far away from home forced us to hang out! If we were an hour south of Bellevue (or closer to me in Los Angeles), it would have been to easy for people to duck out. Instead, for better or worse, we spent almost all of our time together as a team. Finally, I found this particular location to be visually inspirational. We were in beautiful part of the country in a house with a fantastic view. This encouraged the team to work outside, go hiking, play basketball, and simply enjoy the surroundings.
    2. Casual collaboration is awesome. I’m a huge believer in the fact that we learn SO MUCH more during casual conversation than in formal meetings. In fact, I just read a great book on that topic. The nature of the Hack House trip – and even the physical layout of the house – made it so easy to quickly talk through a plethora of topics. I saw the developers quickly pair and solve problems. I was able to spontaneously brainstorm with our Creative Director on some amazing new ideas for our software. I know that “distributed teams” is the new hotness, but absolutely nothing beats having a team together to work through a challenge.
    3. Have a theme for the effort. At Tier 3, we update our cloud software once a month. Our Agile team focused this particular sprint on one major feature area. This focus ensured that the majority of people in the Hack House were working towards the same objective. When we left the Hack House last Friday, we knew we had made significant progress towards it. I think the common theme contributed to the easy collaboration since nearly every conversation was relevant to everyone in the house.
    4. Get to know people. This was honestly one of the primary reasons I went to the Hack House. I work with a ridiculously talented team. Despite being a fraction of the size of the largest cloud computing providers, Tier 3 has the “platform lead” according to Gartner’s IaaS Magic Quadrant (read it free here). Why? Great software and a usability-centric experience. While I’ve worked with this team for over a year, I only knew most of them in a professional setting. Being a remote employee, I don’t get to sit in on many of the goofy office conversations, or randomly grab people for lunch breaks. So, I used some time at the Hack House to simply get to know these brilliant developers and designers. These situations create the perfect environment to learn more about what makes people tick, and thus create an even better working relationship.
    5. Make sure someone can cook. Tier 3 stocked the kitchen every day which was great. Fortunately, a lot of people knew what to DO with a stocked kitchen. If we had just gone out to eat for every meal, that would have wasted time and split us up into groups. Instead, it was fun to have joint meals cooked by different team members.
    6. Get involved in activities. Even though we were all living together, it’s still possible for someone to disappear in an eight-bedroom house! I didn’t see any of that on this trip. Instead, it seemed like everyone WANTED to hang out. We watched Monday Night Football, ate together, played The Resistance (poorly, in my case), and went hiking. These non-work activities were a cool way to wind down from work. What was fantastic though, is that this started at the top. Our VP of Engineering was there for the whole duration, and he set the tone for the work-hard-play-hard mentality. Want to go shoot hoops for a half hour at 2pm? Go for it, no one will give you a weird look. Up for a hike that will get you back by lunch time? Have fun! Everyone worked hard, but we also embraced the spirit of Hack House.
    7. Valuable to mix teams. Our Engineering team consists primarily of developers, but my team (Product Management), Design, and QA also roll up underneath it. All teams were invited to the Hack House and mixing it up was really useful. This let us have well-rounded discussions about feature priority, design considerations, development trade-offs, and even testing strategy. In the next Hack House, I’d love us to also invite the Operations team.
    8. Invest in bandwidth! Yeah, we maxed out the network at this house. 8-12 people, constantly online. I had a GoToMeeting session and somehow kicked everyone off the network! Before choosing a house, consider network options and whether you should bring your own 4G connectivity!

    All in all, a very fun week and productive effort. I’ve seen other companies do weekend hack-a-thons for team building purposes, but an extended period of collaboration was invaluable. If you want to join us at the next Hack House, we’re still looking for one or two more great developers to join the team.

  • 5 Things That I’ve Learned About Working Remotely

    In the past couple weeks there was an uproar in the tech community after it was learned that Yahoo! CEO Marissa Mayer was halting the “work from home” program and telling staff to get to the office. The response among techies was swift and mostly negative as the prevailing opinion was that this sort of “be at the office” mentality was archaic and a poor way to attract top talent.

    That said, I‘ve been working (primarily) remotely for the past eight months and definitely see the pros and cons. Microsoft’s Scott Hanselman wrote an insightful post that states that while working remotely is nice, there are also lousy aspects to it. I personally think that not every person, nor every job, makes sense for remote work. If you have poor time management skills at the office, they’ll be even worse when working remote! Also, if the role is particularly collaborative, I find it better to be physically around the team. I simply couldn’t have done my previous job (Lead Architect of Amgen’s R&D division) from home. There were too many valuable interactions that occurred by being around campus, and I would have done a worse job had I only dialed into meetings and chased people down via instant messenger.

    In my current job as a Senior Product Manager for Tier 3, working remotely has been a relatively successful endeavor. The team is spread out and we have the culture that makes remote work possible. I’ve learned (at least) five things over these past eight months, and thought I’d share.

    1. Relationship building is key. I learned this one very quickly. Since I’m not physically sitting with the marketing, sales, or engineering team every day, I needed to establish strong relationships with my colleagues so that we could effectively work together. Specifically, I needed them to trust me, and vice versa. If I say that a feature is important for the next sprint, then I want them to believe me. Or if I throw out a technical/strategy question that I need an answer to, I don’t want it ignored. I won’t get respect because of my title or experience (nor should I), but because I’ve proven (to them) that I’m well-prepared and competent to ask questions or push a new feature of our software. I also try give at least as much as I ask. That is, I make sure to actively contribute content and ideas to the team so that I’m not some mooch who does nothing but ask for favors or information from my teammates. I’ve made sure to work hard at creating personal and professional relationships with my whip-smart colleagues, and it’s paid off.
    2. Tools make a difference. All the relationships in the world wouldn’t help me if I couldn’t easily communicate with the team. Between Campfire, Microsoft Lync, GoToMeeting, and Trello, we have a pretty dynamic set of ways to quickly get together, ask questions, share knowledge, and track common activities. Email is too slow and SharePoint is too static, so it’s nice that the whole company regularly uses these more modern, effective ways to get things done. I rarely have “real” meetings, and I’m convinced that this is primarily because there Tier 3 has numerous channels to get answers without corralling 10 people into a conference room.
    3. I‘m measured on output, not hours. I found it interesting that Mayer used data from VPN logs to determine that remote workers weren’t as active as they should have been. It made me realize that my boss has no idea if I work 75 hours or 25 hours in a given week. Most of my access to “work” resources occurs without connecting to a Tier 3 VPN server. But at the same time, I don’t think my boss cares how many hours I work. He cares that I deliver on time, produce high quality work, and am available when the team needs me. If I meander for 75 hours on a low priority project, I don’t earn kudo points. If I crank out a product specification for a new service, quickly intake and prioritize customer requests, and crank out some blog posts and KB articles, then that’s all my boss cares about.
    4. Face time matters. I go up to the Tier 3 headquarters in Bellevue, WA at least one week per month. I wouldn’t have taken this job if that wasn’t part of the equation. While I get a lot done from the home office, it makes a HUGE personal and professional difference to be side-by-side with my colleagues on a regular basis. I’m able to work on professional relationships, sit in on conversations and lunch meetups that I would have missed remotely, and get time with the marketing and sales folks that I don’t interact with on a daily basis when I’m home. Just last week we had our monthly sprint planning session and I was able to be in the room as we assessed work and planned our March software release. Being there in person made it easier for me to jump in to clear up confusion about the features I proposed, and it was great to interact with each of the Engineering leads. Working remotely can be great, but don’t underestimate the social and business impact of showing your face around the office!
    5. Volunteer for diverse assignments. When I took this role, the job description was relatively loose and I had some freedom to define it. So, to make sure that I didn’t get pigeonholed as “that techie guy who works in Los Angeles and writes blog posts,” I actively volunteered to help out the marketing team, sales team, and engineering team wherever it made sense. Prepare a presentation for an analyst briefing? Sure. Offer to write the software’s release notes so that I could better understand what we do? Absolutely. Dig deeper into our SAML support to help our sales and engineering team explain it to customers while uncovering any gaps? Sign me up. Doing all sorts of different assignments keeps the work interesting while exposing me to new areas (and people) and giving me the chance to make an impact across the company.

    Working remotely isn’t perfect, and I can understand why a CEO of a struggling company tries to increase efficiency and productivity by bringing people back into the home office. But, an increasing number of people are working remotely and doing a pretty good job at it.

    Do any of you primarily work remotely? What has made it successful, or unsuccessful for you?

  • Book Review: The New Kingmakers

    I just finished reading the fascinating new mini-eBook “The New Kingmakers” from Redmonk co-founder Stephen O’Grady. This book represents a more in-depth analysis of a premise put forth by O’Grady a couple years back: developers are the single most important constituency in technology. O’Grady doubles-down on that claim here, and while I think he proves aspects of this, I wasn’t completely won over to that point of view.

    O’Grady starts off explaining that

    “If IT decision makers aren’t making the decisions any longer, who is calling the shots? The answer is developers. Developers are the most-important constituency in technology. They have the power to make or break businesses, whether by their preferences, their passions, or their own products.”

    He goes on to describe the extent to which organizations crave developer talent and how more and more acquisitions are about acquiring talent, not software. Because, as he states, EVERY company is in part a technology company, the value of competent coders has never been higher.

    His discussion of “how we got here” was powerful and called out the disruptions that have given developers unprecedented freedom to explore, create, and deploy software to the masses. Driven by open source software, cloud infrastructure, internet self promotion, and the new sources of seed money, developers are empowered as never before. O’Grady did an excellent job proving these points. At this stage of the eBook, my thought was “so you’ve proved that developers are valuable and now have amazing freedom, but I haven’t yet heard an argument that developers are truly driving the fortunes of established businesses.” Luckily, the next section was titled “The Evidence” so I hoped to hear more.

    O’Grady points out what a developer-centric world would look like, and proposes that we now exist in such a world. In this developer-driven world, we’d see greater technology diversity (which is counter to corporate objectives), growth in open source, lack of adoption of commercially-oriented technology standards, and vendors openly courting developers. Hard to disagree that all of those aren’t true today! O’Grady provides compelling proof points for each of these. However, in passing he says that “as developers have become more involved in the technology decision-making process, it has been no surprise to see the number of different technologies employed within a given business skyrocket.” I wish he had provided some additional case studies for the point that developers play an increasing role in technology decision-making, as that’s not something I’ve seen a ton of. Certainly developers are introducing more technology to the corporate portfolio, but at which companies are developers part of company-wide groups that assess and adopt technology?

    Next up, O’Grady reviews set of companies that have had a major impact on developers. He analyzes the positive contribution of Apple (in distributing the work of developers via apps), AWS (in making compute capacity readily accessible), Google (openly courting and rewarding developers), Microsoft (embracing open source), and Netflix (in asking developers to help with algorithms and consuming APIs). Finally, O’Grady outlines a series of suggestions for companies looking to successfully use developers as a strategic asset. I thought each of these suggestions were spot on, and I’ll encourage everyone at my company to read this eBook and absorb these points.

    So where was I left wanting? First, if O’Grady’s main point is that companies that treat developers as a strategic asset and constituency will experience greater success, then I’m 100% on board. Couldn’t agree more. But if that point is stretched further to say that developers are possibly the most important assets that ANY company has, then I didn’t see enough proof of that. I would have liked to see more evidence that developers are playing a greater role in corporate technology decisions, or heard about developers at Fortune 100 companies who fundamentally altered the company’s direction. It’s great that developers are influencing new media companies and startups, but what about case studies from boring old industries like government, healthcare, retail, utilities, and construction? Obviously each of those industries use a ton of technology, and often to great competitive advantage, but I would have liked to hear more stories from those businesses vs. the “easy” Netflix/Reddit/Spotify/Zynga tales.

    My second wish for this book (or follow up work) was to hear more about the responsibility of developers in this new reality. Developers (and I speak as someone who pretends to be one) aren’t known for their humility, and works like this should be balanced by reminders of the duties that developers have. For instance, it’s great that developers are more inclined to bring all sorts of technologies into a company, but will they be the ones responsible for maintaining 18 NoSQL database products? What about when they leave the company and no one else knows how to fix an application written in a cool language like Go? How about the tendency for developers to choose the latest and greatest technology while ignoring the proven technology that may have been a better fit for the situation? Or making decisions that optimize one part of a broader system at the expense of the greater architectural vision? If developers are the new Kingmakers, then I’d love to read O’Grady’s thoughts on how developers can lead this revolution in a way that promotes long term success for companies that depend on them. Maybe this book isn’t FOR developers as much as it’s ABOUT them, but I’m selfish like that!

    If you have a leadership role in ANY type of organization, you should read this book. It’s a fantastic look at the current state of technology and how developers can make or break a company. O’Grady also does a wonderful job proving that there’s never been a better time to be developing software. Hopefully he and the other smart fellows at Redmonk will continue to develop this thesis further and highlight both the successes and failures of developers in this new reality.

  • 2012 Year in Review

    2012 was a fun year. I added 50+ blog posts, built Pluralsight courses about Force.com and Amazon Web Services, kept writing regularly for InfoQ.com, and got 2/3 of the way done my graduate degree in Engineering. It was a blast visiting Australia to talk about integration technologies, going to Microsoft Convergence to talk about CRM best practices, speaking about security at the Dreamforce conference, and attending the inaugural AWS re:Invent conference in Las Vegas. Besides all that, I changed employers, got married, sold my home and adopted some dogs.

    Below are some highlights of what I’ve written and books that I’ve read this past year.

    These are a handful of the blog posts that I enjoyed writing the most.

    I read a number of interesting books this year, and these were some of my favorites.

    A sincere thanks to all of you for continuing to read what I write, and I hope to keep throwing out posts that you find useful (or at least mildly amusing).

  • Everything’s Amazing and Nobody’s Happy

    Scott Hanselman wrote an interesting post called Everything’s Broken and Nobody’s Upset this weekend, and it reminded me of the classic, profound Louis CK bit called Everything’s Amazing and Nobody’s Happy. While Scott’s post was reasonable, I’m an optimist and instead thought of a few aspects of technology awesomeness in life that are super cool but maybe unappreciated. This is just off the top of my head while I’m sitting on a plane. I’m using the internet. On. A. Plane.

    • I’m able to drive from Los Angeles to San Diego without changing my radio station thanks to satellite radio. How cool is it that I’m listening to music, from space! No more mindless scanning for a hint of rock while driving through a desert or in between cities.
    • My car has Bluetooth built in and it easily transfers calls from my phone to the car speakers, and when I turn the car off, it immediately transfers control back to my phone. It just works.
    • I’m speaking at Dreamforce this week, and wanted to build a quick Single Sign On demo. Because of the magic of cloud computing, it took 10 minutes to spin up a Windows Server 2008 R2 box with Active Directory Federation Services. It then only took another 15 minutes to federate with Salesforce.com using SAML. IMAGINE acquiring hardware and installing software that quickly 10 years ago. Let alone doing SSO between a local network and offsite software!
    • Yesterday I used my Nokia LUMIA to take a picture of my 4 year old son and his future wife. WP_000172The picture was immediately backed up online and with one click I posted it to Facebook. How amazing is it that we can take pictures, instantly see the result, and share it seamlessly? I recall rolls of film that would sit in our camera for a year and I’d have no idea what pictures we had taken!
    • There are so many ways to find answers to problems nowadays. If I hit some obscure problem while building an application, I can perform broad Google/Bing searches, hit up StackOverflow, go to technology-specific forums and even hit up email distribution lists. I think of doing this years ago when you’d post something to some sketchy newsgroup and hope that HornyInTulsa343 would respond with some nugget of wisdom about database encryption. Bleh.
    • I’m getting a Masters degree in Engineering. Online. I may never set foot on the University of Colorado campus, but each week, I can watch lectures live or shortly thereafter, and I use Skype to participate in the same team activities and same homework/exams as my fellow students. We’re seeing schools like Stanford put classes online FOR FREE! It’s amazing that people can advance their education in so many convenient, sometimes free, ways because of technology.
    • My son talks to his grandmother via Skype each week. They see each other all the time even though she lives 2500 miles away. A decade ago, he’d have to rely on pictures or occasional phone calls, but now when we go to visit my parents, he instantly runs up to his grandmother because he recognizes her. That’s awesome.
    • It’s officially a sport to complain about Twitter, GMail, Hotmail, etc, but can you believe how much free software we have access to nowadays!?! I’m storing massive amounts of data online at no cost to me. I’m accessing applications that give me real-time access to information, establish complex business and social networks, and most importantly, let me play fantasy sports. I watch my colleague Adron quickly organize geek lunches, code camps and other events through the use of various free social networks. That was pretty freakin’ hard to do spontaneously even five years ago.

    Are all the technologies I mentioned above perfect and completely logical in their behavior? Of course not. But I’m just happy to HAVE them. My life is infinitely better, and I have more free time to enjoy life because technology HAS gotten simpler and I can do more things in less time. We as technologists should strive to build better and better software that “just works” for novices and power users alike, but in the meantime, let’s enjoy the progress so far.

    What technologies do you think are awesome but taken for granted?

  • 2011 Year in Review

    2011 was an interesting year. I added 47 posts to this blog, produced three training courses for Pluralsight, started contributing a pair of articles per month for InfoQ.com, released my 3rd book, had speaking engagements in New Zealand, Sweden and China, started graduate school, and accepted a new job. I’m extremely thankful for all these opportunities and I keep doing all this stuff because I find it fun and love learning new things. And I really appreciate the 172,000+ visits to the blog this year and the many of you who bought my books, watched my training and read my InfoQ articles.

    In this post, I’m going to highlight some of my favorite blog posts and books from 2011.

    First off, these are a few blog posts that I enjoyed writing this year.

    It was hard to keep up my regular pace of reading a book or two a month, but I still carved out time to read some memorable ones. I admittedly read fewer deep technical books and focused more on growing as a strategist and learning to manage my time effectively.  Here are a few of my favorites from this year:

    • Your Brain at Work. Great description of what tasks tax the brain most, how to decompose complex ideas, strategies for staying focused and how to be more mindful. Useful stuff.
    • Blink. Gladwell is known for writing provocative books, and this is no exception.  Instead of thinking that the quality of our decisions are based on the time/effort we put into it, we should trust our judgment more often.
    • The Bullpen Gospels. I’m a sucker for baseball books, and this one was immensely satisfying.  It’s a great story of a pitcher’s journey through minor league baseball.
    • Do the Work. Nice little book that encourages us to jump into a task, not fear success, and to remember that “finishing” is the most critical part of a project.
    • The Naked Presenter: Delivering Powerful Presentations With or Without Slides. I’ve worked at becoming a better presenter over the past few years, and books like this help keep me focused on telling a compelling story without using slides as a crutch.
    • fruITion: Creating the Ultimate Corporate Strategy for Information Technology. Good read about articulating the real role of IT in an organization and the value of better alignment with business partners.
    • recrEAtion: Realizing the Extraordinary Contribution of Your Enterprise Architects. If you’re an architect, or even pretend to be one, this is a must-read.  Fundamentally changed my thinking on what it means to be an (enterprise) architect. Continues the fictitious story from the previous book, fruITion.
    • Little Bets. Food for thought about the value of experimentation as most new brilliant ideas don’t form out of thin air, but are discovered.
    • Game of Thrones; A Clash of Kings; A Storm of Swords. I’m not a fantasy book guy, but after watching Game of Thrones on HBO, I thought I’d try the books. I read the first three and loved the characters and “did they really do that?” plot twists.
    • The Two Second Advantage: How We Succeed by Anticipating the Future–Just Enough. Excellent book on the real-time data revolution. Although written by the CEO of TIBCO, the book isn’t very technical but rather shows the reader the significant impact of real-time intelligence.
    • A. Lincoln: A Biography. Fascinating, well-paced story of one of America’s most compelling historical figures. Lincoln was such a deep thinker and this book does an excellent job following his thoughts from early life through his successful navigation of the US Civil War.

    As for 2012, hopefully you’ll see more blog posts, more training courses, and more interviews containing stupid questions.