Throughout human history, teams have been chasing the thrill of victory. Armies, companies, and sports teams put in hours of training and build years of experience in pursuit of winning. Nothing I can write will obviate the need for all of that hard work, but no amount of effort can guarantee you’ll come out on top. There is, however, a single key. Without it, I can assure you that success will always elude your team.

Photo Credit: hoshi7 via Compfight cc

As a firm believer in talent mobility, I’ve worked with teams of all sizes in large and small organizations, across a variety of industries. One benefit of my varied background is the diversity of perspectives to which I’ve been exposed. What a blessing to have had the opportunity to learn from so many others!

I wish I could say that every one of my endeavors had met with success. Sadly, I cannot, and I’m fine with that. The educational value of my experiences with each team is beyond measure. Here’s what I’ve learned: The Key to Success lies in its Definition.

That’s it? Yup. Your team will never win if they are not working toward a single definition of success. It sounds simple, because it is. Yet, time and again throughout my career, I’ve seen teams of smart, hard working people fail because they didn’t define success. Don’t let it happen to you!

Here’s a cheat sheet to help your team:

• The definition has to come first. We’ve all known for a long time that you have to prioritize your work, right? Well, defining success for your team is the top priority for any effort. If you’re playing poker, it comes before table stakes. If you’re playing golf, it comes before paying greens fees. If you’re working on a project, it comes before Sprint 0. Do it first.
• There can be only one definition. The entire team must work toward a single, common definition for success. Different ideas can, and should, contribute to the definition. Once a decision has been made, though, the team has to work together to achieve success. If this is a stumbling block, your team may be trying to do too much, or may need to divide and conquer.
• Success must be measurable. This isn’t to say that your team’s definition of success must be quantitative. A perfectly reasonable definition for success might be: “Mrs. Smith will like the web site”. Irrespective of the unit of measurement, your team needs to understand what success “looks like”, so they’ll know it when they see it.
• The definition must be communicated. Certainly, your whole team needs to understand what it means to be successful. Beyond that, I’d argue that you should share your definition of success with every stakeholder. Being transparent in your communication allows your team to focus on achieving and preempts second guessing during the decision making process. When your motives are clear and understood, you can focus on delivering.
• The definition needs to be central. Every conversation, meeting, or decision should be made in light of your definition of success. All of your hard work needs to contribute to success. I highly recommend kicking off every practice, every meeting, every demo by declaring your team’s definition of success. Stay focused. See the same picture all the time.

I hope this helps your team. It certainly helps me to remember this fundamental lesson. Even after all of the times I’ve seen teams fall short without it, I’m still guilty of diving in without this core component.

One final hint, on that note: If you’re on a team who doesn’t know what success looks like, stop now to define it. The pause will enable future acceleration. Your team and your stakeholders will thank you. Does your team have a definition of success?

I mentioned recently that it’s time to shift your focus from getting things “done” to being “ready”. What follows is a more specific, actionable post about what that means for your team (assuming your team, like mine, is responsible for delivering software solutions)…

Another Devops Definition

If you are in a technology industry today, you are talking about “Devops” (or “devops” or “DevOps”). Business leaders are gravitating toward that term in droves. Before the genie gets out of the bottle, though, and you’re asked to spin up a devops team, I felt it best to set the table for a valuable conversation. I’d argue that devops, done properly, is about being ready for success. Let’s break down what devops means:

• Devops is not a tool, a team, a process or a technology. It is a culture. At it’s heart, it is about an organization focused on a single definition of success. I can’t begin to prescribe what success means for your organization, but it is generally about making customers happy with outstanding products or services. By bridging the gap between the software development lifecycle, IT service management, and business process management, devops establishes a unifying purpose and quantifiable behaviors for every individual to contribute collaboratively to the success of the organization.

Why Does it Matter?

The one thing we can count on in technology is change. In order to be responsive without being reactive, we need to agree on the some fundamentals. With the pace of change in our lives, we must be capable of truly letting go of the notion of getting “done” with our work. We are never “done”, but we must always be “ready”.

Since I tend to think in lists, I’ve built one here to help communicate what it means to be ready. I think it goes a long way to helping an organization adopt a devops culture. Unlike a traditional “checklist”, though, this post should serve as a roadmap throughout the lifecycle of an application/product/solution. Your team can then assess each stage of the lifecycle with full transparency, staying honest with themselves and their stakeholders as they travel the feedback loop together.

Even if adoption doesn’t make sense in all cases, or one team’s definition varies from another’s, the goal remains the same: Begin with the end in mind. Communicate, collaborate and commit to shared accountability for a successful solution. If you decide that a piece of this list doesn’t or shouldn’t apply to your solution, at least you’re making that decision in full light of day. Do what makes sense, and keep expectations clear with absolutely everyone. That is the mark of a technology professional.

Caveat: Don’t use this list as a project plan. Use it as a reference. Go off and prove concepts. Write code. Exploratory work is critical when you kick-off a project. Just be prepared along the way. If you think the launch is the finish line, you’ve already failed.

The Definition of Ready

1. Success is defined. However your team defines success, there must be a single definition. Everyone who has a stake in your project has to be clear what it means to succeed. Without this building block, all the best developers or ops teams or salesman can never be enough.
2. A solution is developed, reviewed, and tested. Whatever set of standards and best practices you decide to adopt (or create), follow them when you develop software. Hold each other accountable to them when you conduct peer reviews. Use them to help the whole team find and fix bugs in testing.
3. The solution is documented. People understand pictures. It doesn’t matter if your team is full of ninjas or rock stars or gurus or whatever other term is en vogue. A solution is not just for developers, or even technical folks. Just draw a picture of the solution and its integration points. If you ever need to consult an outside expert or vendor, or hire a new employee, you’ll be glad you have it.
4. The solution is deployed and accessible. Ideally, you have a handle on continuous delivery. Ultimately, though, you simply need to understand how and where your solution gets deployed. That includes the stages through testing and staging and production. Does the team understand how changes make it to a customer? Is everyone responsible for supporting the solution capable of accessing it?
5. The solution is monitored. Every production solution needs monitoring. I can’t begin to tell you how detailed yours must be. Just be sure that your solution issues relevant, clear and identifiable information when a fault occurs and is being monitored for both faults and performance. Keep in mind, too, as it relates to operations: faults must be actionable. If they aren’t, get comfy with the pager.
6. The solution has clear diagnostics, escalation and remediation. Your solution should be capable of being “smoke tested” with clear red/green results. Those results, just like any faults caught by monitoring, need to be clearly understood by all parties. That includes troubleshooting steps, known workarounds, automated tooling, etc. The point here is to be planning for what can break, how to fix it, and when to call in the experts.
7. The solution is built for high availability and disaster recovery. Are you prepared for a catastrophic outage? Are your customers? Simply checking this box because you deploy to the cloud isn’t going to cut it. Is you solution capable of being completely redeployed to a different environment in a minimally invasive manner? Get rid of secret sauce and tight coupling to environments.
8. The solution provides adequate reporting capabilities. You will be asked for data. Big or small, performance, usage, financials, outages… There are many interested parties. Be sure you are setup to provide answers. If you solution is not capable of providing data for analysis by stakeholders, you’ll be on the spot more often than not. Be ready to answer the questions you’ll get.
9. The solution is staffed. Technology gives us tremendous scale, but there are still people charged with keeping it alive. When there are enough people and they understand how to do what is required, customers never know they exist. That’s a good thing. Remove the people (or try to get by with too few), and the customers will know one person: You.
10. The solution has been communicated. Ultimately, your solution is not yours at all. The product or service you provide and this entire checklist is designed to be shared with the people who are staking their time, money or brain power on the success of the project. I hope you use this checklist as a point of reference to keep everyone on the same page. They need to know if you’re ready. So tell them.
11. Repeat. Iterate. Work hard. Play hard. End of the list. Thought you were done? You’re not done. You’re ready. Ready to do it again and again and again… That’s what success looks like. Congratulations!

There you have it. That’s what I’ve learned in my career at many companies, small and large, new and old. Another thing I’ve learned is that there is much more to be learned from the perspectives of everyone else who’s breathing right now. So, leave a comment or a question. I’m ready to keep learning!