By Kent Corley
Read more about this author

Recently, I saw a TED Talk by Simon Sinek around how great leaders and organizations inspire action. It made me think about my new role heading up Strong Bridge’s Technology Services practice area. In a nutshell, Simon says that rather than focusing on the “What and How” to accomplishing something, great organizations start with “Why” and let that drive the “What and How.” “Why” is based on a set of shared beliefs and values that these organizations expose and foster. This applies to technology as well.

Why do we recommend a specific approach in technology? What are those shared beliefs and values that influence the decisions we make? In order to better understand the “Why” of our tech practice, I am sharing some key beliefs that ground me when clients ask for technical guidance on a solution or approach.

The following (in no specific order) are generalizations. There are always exceptions to the rule. These beliefs were formed over time and through experience “deep in the trenches” of technology. They help me define “Why” I do what I do. Some of these may be a little controversial, but it is important that we challenge our view, either to validate it or evolve our approach.


1. Technology can improve peoples’ lives and is a force for good.

This is what I would call a foundational belief. Many in technology share this one, or we wouldn’t be here. As kids, we often read science fiction and saw the wonder in the future. Today, I remain inspired by the wonder of technology every day. Stories of cell phones helping farmers set better prices in sub-Saharan Africa, or Big Data being used to analyze genomes to find therapies for terrible diseases — we are only at the beginning of where these powerful trends are going. This is why I get up in the morning.

2. Information Technology is a specialty, not a commodity.

When you embark on delivering technology, you should do it well or not at all. I once saw five amazing, highly-skilled, and passionate developers at a start-up build an extremely valuable system (and associated business) with hundreds of thousands of lines of code in a year. I have also seen hundreds of people deliver very little over multiple years. What this means, unequivocally, is that individuals matter and technical excellence matters. Passion for excellence and a culture that reinforces it matters. “Cheaper,” particularly in terms of developers, is rarely better.

3. A relentless focus on customer value is critical in delivering technology.

I have seen million dollar systems put on a shelf and never used. I have also seen cloud systems that cost a few hundred dollars a month deliver critical core capabilities for large organizations. The difference is, what helps you deliver the most value for your customers. Be very suspicious of large technical investments that are labeled as foundational that can’t be directly related to how it helps your customer. This is not to say one should not invest in infrastructure, but, if someone asks for a lot of money up front, where the benefit is in the distant future— be very afraid. Speed is a key strategic advantage, and the faster capabilities are delivered to customers, the more value there is.

4. Technology should be tested with customers as quickly as possible.

Many of us have seen the cartoon of the tire swing depicting “what was asked for, what was specked, and what was delivered.” Giving customers access to what people are working on has some risks, but the greater risk is spending considerable time and money on something they don’t want. There are many approaches around this, such as Agile, fail fast, continuous delivery, etc. But, it all amounts to “show me.” When you show what you are doing, you build trust and enable far greater collaboration and feedback loops.

5. Tools can sometimes make things harder if the implementation isn’t done right.

Every software sales rep says he or she has a better mousetrap. If you just buy the license, all your problems will be solved. I bet every company wishes it had every dime back it wasted on shelfware it purchased. This invariably happens where people lack a full understanding of the cost of implementing a tool correctly. They don’t fully understand in the beginning how will it improve daily processes or how is adoption will be driven. Writing a check may be easy but does not imply a successful roll out or implementation. It is “people, process, and technology” — in that order. Be very wary when you are in a sales pitch and the rep is focusing on the reverse.

6. Time zones can kill technical innovation and collaboration.

Building technology is really the act of taking something abstract and making it concrete. Anything that stands in the way of that process can have huge impacts on productivity and the value of what is being created. Don’t underestimate the value of two people in a room with a whiteboard. Ideally, one person is a business person with the idea and the other person is technologist responsible for building it. This is the basis of Agile delivery practices and why they can work so well. I don’t know how many times I’ve been told, “We need to specify our {requirements, designs, etc.} so well a monkey can implement them.” If you have these artifacts to such a low level of specification, you can generate the code and put the monkeys out of business. You tend to spend lots of money on expensive FA/BAs documenting the solution to save money on cheap developers.

7. The world is going to the cloud, and everything that isn’t in the cloud will still need to talk to it.

Running a data center is like a company building out their own power plant. Sometimes it does make sense if a company is in the power business, or isolated from the grid, but these are very rare cases. Cloud providers are getting better and more efficient every day. These providers are also moving up the stack from infra, to platform, to application. If your core competency isn’t managing technology, get out of that business as fast as possible. If you build something, it should be a differentiator for your customer and related to your own special sauce. For things that don’t run in the cloud, know that they will need to talk to the cloud. Internet of Things (IoT) is going to change the world more than people expect. Just remember this, Alexa is a very dumb piece of hardware, which is why Amazon only charges $39.99 for it. The cloud it’s connected to is where its value lies.

8. Systems should consist of industrialized decoupled components.

This very old concept dating back to the Revolutionary War and replaceable gun parts. More recently, Smalltalk, arguably the first object-oriented programming language, was released in 1980. What has always been the challenge is data isolation. People write a bunch of objects that all talk to an integrated relational database. The power of the cloud, DevOps, and componentization technologies are starting to be realized through decoupled microservices. Data isolation is becoming realized, and we may finally start to see the demise of relational databases (although that is a dangerous prediction as Larry’s World Cup boat demonstrates). When you isolate these services, they can be tested and deployed on their own.  The reason you have six month release cycles, huge change management meetings, and armies of architects, is directly related to system coupling. Removing that frees you to release thousands of times a day as Amazon does. Which delights your customer more: “You will get that feature in six months, or, “I can give that feature to you today?”

9. Organizational barriers between business and technology are archaic and counterproductive.

I have met many executives, including those in technology, that say, “I don’t understand all that complex tech stuff.” I think this can be a cop-out. It is like someone with an MBA in marketing saying, “I don’t understand all that complex finance stuff.” Having an understanding of technology, at least at a high level, is critical for executives to do their jobs in the 21st century. The companies that are the best at delivering technology to their customers are becoming much more vertically integrated in how they execute the software delivery pipeline.

Business people and technologists each have the responsibility to work earnestly to understand each other. Technology is moving into marking organizations through digital groups and vice versa, whereas CTOs own all tech in a company including product management. When you have decoupled services and tight alignment between business and technology, or when they are in the same team, you can deliver capabilities to your customer at a vastly increased rate— feedback flows back quickly to the product or marketing managers so they can iterate quickly to change and optimize features for better and more targeted value.

10. Security should be an integral part of everything you do.

I have been in many situations where a company hires an expensive technology consultant at the end of the project to “secure the system.” Honestly, at that point, it is too late. The best way to build security is to do it from the beginning, and ensure everyone is accountable. It begins by not putting sensitive information in a system to begin with. I have followed a rule my whole career to never put anything in an email that you don’t want on the cover of The New York Times. The corollary in system design is to not persist sensitive data like social security numbers and other sensitive information. We should also make it easy for developers to build secure systems by providing facilities or frameworks that support security at the platform level, such as encryption data at rest, authenticate at the user level, and log when users access sensitive information. Finally, after you have done these blocking and tackling things, there is value in having specialists come in and conduct penetration testing to provide additional confidence in the security of the system.

These beliefs can help guide strategy around how to deliver technological solutions at your organization. Our own Technology Services incorporate these beliefs into actions every day. For instance, Product Delivery Transformation is about helping business people and technologists work together using Lean, DevOps, and continuous deployment to build out customer capabilities rapidly, and without sacrifice to quality. Ultimately, the thing to remember is that having a belief system that is built on facts, forward thinking, and experience will help you better understand and articulate the “Why” of your technology strategy, and provide a solid foundation for the “What and How.”

Interested in knowing more about us? Feel free to send us a note