Data, data, data

"Data, data, data" is the new "location, location, location."

Uber owns no taxis, yet is the largest taxi company in the world. AirBNB owns no real estate, yet has the most accommodations in the world. These companies run their businesses on data, and lots of it.

Data is king, and it is only becoming more important. Proper analysis and utilization of data helps to uncover the what, the why, and even predict the future. As a result, data must be a core component of your digital strategy.

Hindsight
At the most basic level, data gives us hindsight. A simple example is how grocery stores utilize loyalty cards. Customers sign up for them with some basic personal information, and in return the store gives the customers discounts when they use their card. Data collected from these cards helps the grocer identify individual purchasing habits -- it gives them hindsight.

This is why online retailers encourage customers to create accounts. The data collected (which products are being viewed, which terms are being searched for, etc.) all help track what is happening in their store.

Insight
Understanding the "what" is just the basics when it comes to data analytics. Having the view into the "why" provides insight.

Why do certain customers buy one product over another? Why do certain products sell better at certain times of the year? These are the types of questions the data can help provide insight into.

Foresight
Being able to predict behavior is the next step; this is where the most positive transformation can occur for an organization.

Again using grocers as an example, stores can use big data to predict and suggest the price points of certain products at certain times to ensure the right amount is in stock and fresh. If the price of strawberries, for example, is too high grocers risk having too many in stock and the strawberries going bad. If they accurately predict the right price point, they can keep the right amount moving off the shelves at a pace that ensures each package is still fresh.

Lastly, there are some scenarios where proper data analysis can actually help to prescribe some actions. In other words, using data can help make things happen.

Let us use the car company Fiat as a fictitious example for this. If Fiat mined the publicly available social media posts specifically looking for terms which suggest a propensity to buy their car, they may be able to help drive more sales. The scenario could go something like this: John Smith posts to Twitter, "Thinking about buying the new Fiat. Can't decide between that or the Toyota Prius." That post will get picked up in Fiat's social media scanning algorithm, and alert the salesperson in John's region to contact him directly. That contact may help to influence John in purchasing a Fiat.

Making it happen in your organization
To leverage data effectively, naturally you need data. Determine the sources, and if none exist start setting up your data collection processes.

Once you have the data, it needs to be usable. Having it in 25 disparate systems will make life tough. Rather centralizing it and "cleansing" it for use (i.e. ensuring accuracy, removing duplicates, etc.) is key.

Additionally, data can help create a source of revenue. Identify any data which may be unique to your organization which others externally may pay to access. Ensure proper usage controls and governance are in place.

Also keep in mind potential external integrations or partnerships.

Ultimately, there are endless possibilities to how you can utilize data. Start small, take an MVP approach, and build from there as you learn what works for your organization.

High-performing teams, Part II - Being proactive

There is not one thing which creates a high-performing team (HPT). Trying to define the numerous aspects of an HPT culture took me an entire blog post. However, being proactive is one key attribute required for all individuals of a high-performing team.

Doing what is expected
My prior post discussed team growth expectations. In order to achieve continuous growth, each individual simply doing what is expected of them is not enough for achieving HPT status.

Take a software developer, for example. They are expected to create X features working on Y product while collaborating with their teammates. They are expected to complete those features on time, follow proper standards, and ensure their code is efficient and secure. That is the baseline. That is expected of them each and every day. While that may sound great, my view is if everyone on the team did that year after year team growth would be stagnant. (And it may get boring for the developer!)

Being proactive
Being proactive is the key to unlock exponential growth and creativity in both individuals and teams.

The definition of proactive:

Creating or controlling a situation by causing something to happen rather than responding to it after it has happened.

Take a software developer again as an example: They can be proactive in numerous ways, including identifying a new solution to a problem the team is facing (without being told, of course), implementing it, and organizing a lunch-and-learn session to ensure everyone is aware and understands the new way forward.

The key is for individuals to take the initiative in looking for ways they can help improve themselves, the team, and the company. This is often where new and creative ideas emerge, which naturally leads to learning and mastery.

The proactive expectation (and contradiction?)
I argue being proactive is therefore expected of all team members.

Does this mean, however, any proactive work is then simply viewed as par for the course? Does this mean no individual can ever be seen as going above-and-beyond?

No. The beauty of being proactive is while it is expected of everyone, there are so many ways in which it can be done. Therefore, it is impossible to define exactly how to do it, so it can never be explicitly expected.

Team growth expectations

Most companies have year-end performance reviews. This is a time to reflect on how each individual has performed. Managers have a critical responsibility to also look at the team as a whole.

• Is the team growing overall?
• Where is the team this year compared to last year?
• Is the team well prepared for the year to come?

Each team is expected to continuously grow.
Each team may define growth differently, but I like to think of team growth as the collective improvement of skills (both technical and "soft"), processes, and tools. A high-performing team knows they must continuously improve to remain ahead of the competition. This implies constant growth.

New things means new challenges; expect them.
In order for team members to grow, managers must provide the space and a safe environment where trying new things and failure are OK. Managers should expect small bumps in the road ("growing pains") when new things do not work out or take time to learn. As long as they are followed up quickly by learning and more improvement, failures are OK.

Doing the same as last year is unacceptable.

These new improvements will become common knowledge, and collectively the team will grow. This sets a new bar for the team to aspire to. The collective team's growth means every individual is expected to keep pace. Someone performing at the same level the team was collectively at a year or two ago is now significantly behind pace. These individuals must demonstrate an immediate improvement.

I try to illustrate these expectations in a very rough graphical sketch below. The green line represents (at a high level) the overall growth of the team. Highlighted are sharp improvements (perhaps a new process was implemented, for example) followed by small declines, or "growing pains." The team's collective growth sets the bar for the next year, and all the individuals are expected to keep pace.

Measuring anything

Most projects require some sort of measurement to obtain approval, determine viability, estimate return on investment, etc. It can appear challenging to think of how to measure risk, productivity, profit, etc.; however, Douglas W. Hubbard's book, How to Measure Anything, demonstrates anything can be measured, and in more practical ways than you might think.

A reduction of uncertainty
It is important to note how Hubbard defines measurement: observations which quantitatively reduce uncertainty. This is key as it takes the pressure off individuals for having to be exactly precise in their answers. Especially when just starting out, even a small reduction in uncertainty can be a large step toward a particular outcome. Hubbard points out that even sophisticated scientific experiments have margins of error; measurements for business are no different.

Really, anything?
Yes, anything can be measured. (Although not everything necessarily should be measured.) Hubbard suggests the following to help demonstrate this:

If it matters at all, it is detectable, observable.
If it detectable, it can be detected as an amount or range of possible amounts.
If it can be detected as range of possible amounts, it can be measured.

Determining the "what"
Understanding why you want to measure something helps guide the scope of what can be measured. For example, someone may say, "We want to measure IT security." The first question to ask is: what is IT security? From there, you should be able to identify particular objects of measurement within each part of your answer. Once you have your object of measurement and understand what it means, you are halfway there.

It is easier than you think
When we are struggling with measurements, Hubbard reminds us of the following:

1. Your problem is not as unique as you think. Recognizing that others may have solved similar types of problems in the past may help to put things in more perspective.
2. You have more data than you think. Some data is better than none. 
3. You need less data than you think. Again, we are not looking for 100% certainty.
4. An adequate amount of new data is more accessible than you think.

Obtaining measurements
Hubbard's "Applied Information Economics" has 5 steps to help obtain measurements. I try to summarize them below:

1. Define a decision problem and the relevant variables. Asking "why?" helps here. Start with the decisions you need to make, then identify the variables which would make your decision easier if you had better estimates of their values. What is the decision this measurement is supposed to support?
2. Determine what you know. Quantify your uncertainty about those variables in terms of ranges and probabilities. Hubbard uses the term Confidence Interval (CI) to gauge the level of uncertainty for a certain interval. A 90% CI would be one in which there is a 90% chance all outcomes fall in the interval you provided. For example, my 90% CI for average commute times in my office is 30-70 minutes. It is important to be "well-calibrated" in giving your 90% CI. Hubbard suggests the equivalent bet test as a way to gauge how calibrated you are.  
3. Pick a variable, and compute the value of information for that variable. Some variables' measurements will be more valuable than others. The goal is to find the variable with a reasonably high information value. (If you do not find one, then skip to step 5.)
4. Apply the relevant measurement instruments to the high-information-value variable. Go back to step 3 to repeat this process with any remaining high-value variables.
5. Make a decision and act on it. 

Hubbard suggests at least 10% of the project budget for large efforts be spent on performing measurements to first justify the investment.

Note: Beware the "measurement inversion." Hubbard warns that most managers tend to measure the data which are easiest to obtain, but provide the least amount of economic value. Hence why step 3 above is critical.

Measurement instruments

Hubbard outlines the following to help start us toward our measurements:

• Decomposition: Which parts of the thing are we uncertain about?
• Secondary research: How has it (or its parts) been measured by others?
• Observation: How do the identified observables lend themselves to measurement? Can you create a way to observe it indirectly?
• Measure just enough: How much do we need to measure it?
• Consider the error: How might our observations be misleading? Consider things like confirmation, observer, and selection bias. 

Hubbard describes at length many different types of measurement instruments like controlled experiments, regression modeling, and Monte Carlo simulations. I will highlight just a few of those which do not involve too much (or any) math, because I think it is important to have a few straightforward methods "in your pocket:"

• Rule of 5. There is a 93.75% chance that the median of a population is between the smallest and largest values in any random sample of five from that population. This rule allows us to obtain a CI greater than 90 by only sampling a small amount of the population. 
• Spot sampling. Determining how many fish are in a lake can seem impossible (unless you drain the lake!), but spot sampling can help here without draining the lake. In this case, a biologist might catch 1,000 fish, tag them, and release them back to the lake. A few days later she may catch another 1,000 fish and see that only 50 fish (5%) had a tag on them. This means there are approximately 20,000 fish in the lake.

Simple personal example
I'll conclude with a personal example of how understanding that anything can be measured can help expand possibilities. I was in a senior management meeting on a topic around improving our company's leadership, and someone said, "It is almost impossible to measure the performance of managers."

So I suggested the following:

1. What things do we consider make a good manager or leader? 
2. Of those traits, what are ways we can observe and measure those?

The group discussed many areas like team performance (which itself needed to be broken down further to define measurements), as well as retention/attrition rates, referrals (i.e. employees referring friends for open positions under that manager), promotions, etc.

The group was able to identify why measuring manager performance was worth measuring, and as a team identified possible measurements. The next step would be for us to put a value on each variable, and decide what decisions the measurements would be used to support.

Be open: Integrate and let integrate

A key principle I drive at my organization is technical openness. This means all the tech we leverage should be based on open standards and frameworks. There are many reasons for this, including:

• Superior interoperability and integration with other systems.
• Prevents "re-inventing the wheel."
• Avoids being locked into proprietary and costly technologies or vendors.
• Improves agility and choice; can select best-of-breed solutions for each job.
• Broadens support pool and timelines.
• Increases innovation, as open standards invite everyone to participate in providing feedback.

I believe the ability to integrate fast and effectively is a skill which all companies will need to survive over the next few years. This is why the first bullet above is most critical.

Examples of key business integrations 

Here are a few "integrations" which help drive business growth:

1. Pizza Hut can be ordered directly through Amazon Echo (Alexa). Amazon provides vendors a standard way of connecting to their Echo service, and companies like Pizza Hut are able to connect their ordering systems to allow for another potential revenue stream. Pizza Hut was one of the first onto the platform because their systems allow for integrations with external sources to place orders.
   
   
2. Uber is a great example of being able to integrate with various channels. Users can request rides directly within both Google Maps and Facebook Messenger. They try to capitalize on being available to request a ride at the exact moment when someone is likely to need one.

The examples above demonstrate the need for enabling the in-the-moment, simple, and fluid purchasing capabilities. None of which would be possible if the systems were closed and unable to move quickly to meet the changing dynamics of their users. 

There are other examples which do not include purchases, but rather provide information or other service more easily through atypical channels (see KLM's Messenger integration, for example). Those help to drive customer engagement, satisfaction, and loyalty. All wins for good business, and only possible with open technologies.

Integrate and let integrate!

The future: Our fluid connectivity

I enjoy making predictions about the future. It is fun to see how accurate the predictions are as time goes by.

I believe the technologies of the future are a continuous building upon the present. At times inventions may appear to be huge leaps, but in reality they are logical progressions of existing ideas or novel combinations of both existing and new.

The iPhone, for example, can seem extremely ahead of its time (it was, of course, as compared to the competitors), but even that device was a combination of existing tech. As Steve Jobs introduced the iPhone in 2007, he said it was a:

1. Widescreen iPod with touch controls,
2. Revolutionary mobile phone, and
3. Breakthrough internet communicator

MP3 players, mobile phones, and the networks required to communicate over the internet all existed before the iPhone. But the iPhone brought them together in novel ways.

The "problem"

Many innovations aim to solve problems or enhance our way of life. My prediction is no different. Here are some "problems" which I envision can be enhanced:

1. We are dependent on physical screens to access our digital world. TV's, computer monitors, and smartphones all have screens. They are a fixed size, and TV's and PC monitors generally are fixed to a single location. Even with laptops and smartphones, moving around while looking at the screen requires coordination and one or both hands.
2. With these many devices comes different data stores and modes of authentication. At your PC you may store documents, photos, etc. While your Xbox is used for gaming, and your smartphone for apps. Each one is registered to you in some way, usually authenticated by some form of a password. 

The problems listed above may not seem like problems to you, but to me it seems inefficient to depend on so much physical hardware (especially screens and monitors).

My present-day connectivity is intermittent, bouncing between all devices. Here is a typical weekday:

• I wake up and check for any important messages on my smartphone.
• I arrive at work and utilize that PC for work in my office.
• I come home and use my laptop for browsing the web and other personal work. Maybe watch something on TV as well.
• While throughout the day I may have several brief interactions with my smartphone.

Each bullet above requires actively seeking out, authenticating, and differentiating the devices for specific tasks.

My prediction: hyper fluidity
Like the iPhone, my prediction builds on and combines many existing technologies:

1. Wireless hard drives. These devices allow you to connect your data to any device over Wi-Fi. This is useful as it removes the need for wires or complicated connections requiring software, drivers, etc.
2. Smartphone to laptop. This invention allows you to turn your smartphone into a laptop (kind of). Plugging the phone into a special laptop gives you essentially a full laptop experience running off the phone's software.
3. Authentication apps and tech. These allow you to authenticate with other services using a two-factor approach or your fingerprint, eyes, etc.
4. Voice and gesture control. Think Amazon Echo and Xbox Kinect.
5. The cloud. Software as a service through cloud providers is key as it reduces the need for both hardware and software at every endpoint.
6. Drones (of course). Drones are getting quite sophisticated. They can stick to walls and ceilings, and can even coordinate among themselves.

My vision is one of hyper-fluid connectivity. Where your data, files, etc. are always within "reach," but you do not use your hands. Where authentication is seamless. Where moving from business to personal is instant. And where you are not tied to a specific location.

Imagine having a cup of coffee at your kitchen in the morning, and wanting to see the news. Why lug your laptop over? Why pull out your smartphone? Why not be hands-free and have your super-quiet smart drones do it? And they'll do it in a way which ensures proper posture by putting a display at your exact eye level.

Here's a concept sketch -- note that the screen in this is not a typical monitor simply being held up by the drone, rather it could be a projection or other type of light-weight and re-sizable display medium.

Illustration by Empty Bee Artwork & Photography

The Smartphone to Laptop idea listed above demonstrates the desire for people to need just one device for everything. My prediction is that one device will turn into something which can help authenticate and connect to a fleet of drones. It will be the bots who know who you are and which apps, files, etc. you have access to. There be significantly less need for traditional physical screens or monitors. A display will be able to appear anywhere the necessary amount of drones can go.

Our phones may get smaller, and used simply for as a secondary authenticator. Allowing us to connect to drones and other bots as needed. The drones will learn our preferences, styles, and eventually be able to predict what we want. It may not just be displaying the news while drinking coffee, but also making the cup of coffee. 

Will I buy a new TV soon? Yes, probably. But I am hoping soon after I will just need to buy 4K-capable projection drones with internet connectivity, authentication, and swarm capabilities to coordinate between my other ultra-smart drones.

UPDATE (10/24/16): I feel like we are one step closer to the vision above based on this amazing research done by the Ishikawa Watanabe Laboratory in Tokyo. Their image projection technology can keep an image stable even with a moving target object as the screen. Here is their video:

Do DevOps

DevOps is not a buzzword; it is the way quality software gets deployed fast.

In order for software teams to truly embrace DevOps, they must have an inherent continuous improvement culture which embraces ruthless amounts of automation. Many of my examples below will be Java-specific, but this can apply to all types of software languages.

The deployment pipeline
Your deployment pipeline is critical to enabling speed, so I will expand a bit more here. Some questions to ask yourself: How often do you deploy code to production? How long are your builds? How long does it take to do a production deployment? How often do we have bugs in production? Staging/UAT? Dev? The answers may vary based on many factors, but odds are, you can improve dramatically in all areas.

• Continuous integration. Enabling a distributed group of developers to integrate their local code into a shared development environment as efficiently as possible is the key first step. Generally a build server (like Jenkins or Bamboo) can help to enable this. Most importantly, though, are the automated tests which run on the code before moving it to development. These can be things like PMD or SonarQube which check for best practice violations, standards, or bugs. Similarly, unit, integration, and security tests can and should be run here. The key is code is not allowed to move to development until all tests are passed. We strive for quality, production-ready code even in development.
  
  
• Peer code reviews.* This is probably the only manual step of the deployment process. Having an additional pair of (usually senior- or architect-level) eyes helps to drive team standards, code re-use, scalability, security, and efficiency. Some teams may find it hard to incorporate this critical step, but it must become part of the process.
  
  
• Automated testing. Automated tests can occur at each stage, either with each build (depending on speed), or some regular rhythm (like nightly). These tests can be regression, smoke tests, integration, or performance tests. Visibility of the results are key, as test failures must be addressed promptly. Regular testing also helps to ensure tests stay current. As the test suite grows to have a comfortable percentage of coverage, code can move faster to production with less manual testing.
  
  
• Auto-build, auto-deploy. The build servers mentioned above can automate the process of building and deploying code to each environment. Moving to production may require additional steps due to segregation of duties and change controls. As a result, I recommend making everything standard changes -- this way a change control ticket can be opened automatically by the deployment process rather than requiring manual change controls to be approved. In the lower environments, builds and deploys can be scheduled automatically or occur automatically once new code is committed.
  
  
• Same artifact in each environment. Consistency is key in ensuring quality. Using the same artifact (or Docker image if you use Docker) throughout each environment minimizes variability.
  
  
• Visibility. It is important that with all of the above it is easily accessible and visible to all stakeholders -- from the project managers to the developers. Broken builds, for example, need to be remediated fast as they prevent code from moving for the other developers.
  
  
• Forward and back. Getting to production quickly is important, but it is also imperative to have a way to revert deployments fast. Your pipeline should support this.

Configuration management
Configuring and managing environments in a streamlined and automated fashion enables speed and consistency. Configuration management tools like Puppet or Chef enable centralized management of multiple servers at once. This is key to being able to quickly spin up or down new environments as needed, patch, or ensure the same settings are applied to each without individually tending to each.

These tools can also be used to push software to desktops. This is useful for a team of developers looking to ensure everyone has the same version and configuration of tools on their machines at all times. It also helps with installing those tools as it can literally be a simple double click and go get a cup of coffee.


Containers & container orchestration
Step aside VM's, containers are the new thing. Docker containers wrap your software in a complete filesystem. It is more lightweight than a VM, and enable speed through ensuring standardization of the environment. Their small size means you can have several containers inside one VM. The key point being that containers enable true application portability, as they abstract the underlying infrastructure from the app itself.

As your environment grows with more and more containers, orchestration tools like Kubernetes become important to help manage them all from a central place.


Situational awareness
It is key for the team to know the health of the system at all times. It encompasses the following:

• Monitoring. A constant pulse on the key metrics (response times, CPU usage, server memory, etc.) allows for quick identification of potential issues and can help prevent failures. Tools like Icinga can even automate the creation of monitors when setting up servers through Puppet, for example. I recommend making as much of these metrics visible using tools like Graphite, StatsD, and Grafana.
   
• Logging. Having additional details at hand help to give more insight into the various systems. Centralizing logging outputs using the ELK stack (Elasticsearch, Logstash, Kibana), or using tools like Takipi can help to reduce the time it takes to remediate issues.
  
  
• Alerting. In addition to visual dashboards, automated alerting of key thresholds plays a key role in ensuring timely resolution of issues. A tool like Seyren can be useful here in conjunction with Graphite.

Zero downtime
Who likes staying late or working on the weekend to push new code live? No one. One of the main reasons why this occurs is because many deployments incur downtime in some fashion. With a streamlined pipeline, and a little help from Docker, staying late may become a thing of the past.

When we push new code live, we launch a second Docker container in production and point only our internal network traffic to it using Vulcan. If all tests pass, we point all traffic to the new container (using Redis to maintain sessions) and we are live without any downtime! The same can be done in lower environments as well.


Conclusion
Ultimately we want to achieve a continuous delivery state, where code changes have the potential to go live very quickly, with high assurance of quality at each step. Visibility is key to this process, as it ensures everyone is on the same page.

Lastly, the term DevOps is the combination of Development and Operations. Traditionally development teams and operations teams have competing priorities: devs want to move code to production fast; ops wants to keep the environment stable. With DevOps, the developers take more ownership throughout the process, while operations get involved earlier, more automated tools, and better visibility of the pipeline. The partnership is what drives great business results.


*Side note on peer code reviews: There may be a times where code reviews seem a bit of a burden.

First, when refactoring is required/requested by the reviewing person. Refactoring is an important and natural part of keeping the code base in good order over time. There may be times when refactoring may not be possible due to time, which I would then suggest that a user story (requirement in Agile) is added to the top of the backlog and done in a subsequent sprint (keeping in mind that there is nothing more permanent than temporary code). If you are following Scrum, ensure your teams do not consider their user stories to be "done" until all the code review comments are addressed.

Second, when there are disagreements between the reviewer and the developer. This is pretty simple to resolve, especially when the reviewer is an architect -- the developer does what the architect says. Discussions are always welcome, but tie goes to the architect.

Empathy, above all else

In writing my series about high-performing teams, I thought to pause on the one key element required in all forms of leadership. Without this, your teams will not develop a sense of trust, cohesion, or feel safe. That key element is empathy.

Empathy is different than sympathy, which Brené Brown does a great job explaining in this short video:

Brown discusses what she views as the 4 qualities of empathy:

1. Perspective taking -- Being able to see something from someone else's view.
2. Staying out of judgement -- Refraining from passing judgement on someone, especially without knowing the full story.
3. Recognizing emotion in others.
4. Being able to communicate the above.  

Simon Sinek, whose talks I highlighted before, speaks to the incredible impact great leaders have in creating a culture of safety and empathy, and the positive results which follow: 

One of Sinek's most powerful examples of empathy is the military captain awarded the Congressional Medal of Honor. Captain William Swensen ran into live fire in Afghanistan to rescue wounded soldiers. One of the medics in the rescue helicopter had a GoPro camera, which captured the moment when Captain Swensen helped bring a wounded soldier into the helicopter, then bent down and kissed him, before heading back to the field to rescue others. 

Sinek uses the emotional story to make us reflect on our own teams. How many of your employees would you do something like that for? How many of your employees would do something like that for you? For others? I am not talking about the kiss specifically, of course, although that in itself helps to demonstrate the deep bond between the captain and his soldier. 

Sinek says, 

"In the military they give medals to people who are willing to sacrifice themselves so that others may gain. In business we give bonuses to people who are willing to sacrifice others so that we may gain." 

In a different example, Google's Chade-Meng Tan describes how empathy at work helps to improve people's lives, and ultimately the world. The Jolly Good Fellow... Which Nobody Can Deny (yes, that was his official job title) recently retired from Google to pursue his mission of helping to create the conditions for world peace. I am truly inspired by him and his work.

In the video, Tan speaks about how inner peace, inner joy, and compassion help to enable happiness and reduce stress. He alludes to mindfulness and promotes meditation to raise self-awareness. This self-awareness in turn guides us to be more compassionate and live with more empathy.

I believe empathy is the single most important attribute for leaders. With it comes many inspiring and positive outcomes that can make yourself, your team, and even the world a better place. 

High performing teams -- Part I: Culture

We all want our teams to be high performing. Here are just a few general traits I associate with high performing teams:

• Team members collaborate extremely well, with deep trust and openness;
• Consistently output high quality;
• Deliver at a rapid pace;
• Continuously learn and able to shift to new areas;
• Demonstrate innovation and creativity;
• Strong customer focus and knowledge;
• All team members contribute to their work and also proactively seek to improve the team;
• Has the same goals, moves in the same direction.

How do you create high performing teams? It takes a bit of effort across several different areas. I will try to use my experience to provide a framework, starting with culture.

CULTURE

Having the right culture in place is the first step toward achieving high performance. Here are some key areas I focus on:

• Relentless optimism. Doubt, fear, and negative outcomes from past experiences can hinder individuals, and bring down the entire team. With a positive outlook comes more possibilities. More possibilities bring infinite upside.
  
  Relentless optimism must start from the top. Leadership has to believe in positive change, positive results, and envision a future that is bright.
  
  This also means the senior members of the team (those whom the team look up to) need to pay attention to seemingly minor things like body language in meetings, and wise remarks that may spark doubt into others. There cannot be rolling of the eyes or anyone blurting out "Yeah, right!" Statements like, "This will never work," should be replaced with, "This could work if..."
  
• Ownership. When individuals are held accountable for their deliverables, they are more likely to ensure its quality.
  
  Leadership must identify areas where they want the team to take full ownership of their work. The team can also help to identify ways they want to be measured or demonstrate accountability. It is important for leadership to truly step away here; allow the team to be autonomous in their solutions while never micromanaging.
  
  Taking ownership should not be dreaded, rather done with pride. Leadership must help paint this light, recognizing that demonstrating a lack of ownership (perhaps as first examples for the team) could be challenging. So I remind leadership to ensure praise is given to those doing well.
  
• Failure + rapid learning is OK. A high performing team knows that it is fine to fail fast and cheap, as long as they learn from it. A team creating a new product, for example, does not want to find out it will not sell in the market after 18 months of development. They want to test their hypotheses and obtain feedback early to ensure the company does not waste time and money.
  
• Continuous improvement. The team must have a constant and proactive urge to improve processes, products, tools, and each other. I wrote about the bad words in a previous post -- those must all be removed in some fashion. I also wrote about finding the time to innovate through automation and elimination -- the essence of continuous improvement.
  
  Leadership must also make time for learning and development. Sending employees to courses can be beneficial, but how many of them are truly worth the time and money? Pick and choose wisely, and ensure results from training can be measured and demonstrated. Look for other avenues to embed training in ways which engage the team more. This takes a deep understanding of the individuals on the team, and how they operate.
  
• Need for speed. Each team member must have an eye on the speedometer. What is slowing down the process? How can we get something out the door faster? This is similar to a continuous improvement mindset, but focused strictly on speed to deliver.
  
• Safe to speak up. In order to achieve a lot of the above, the team must feel safe to speak up. Challenging status quo can be uncomfortable if leadership is not open and does not truly listen. New ideas will not emerge from team members if they are continuously stifled or ignored. Create an environment where everyone feels like their opinion is valued and they can make a difference.
  
• Have a purpose. With everyone moving toward the same goal, vision and standards of work, the team will move in lock-step even when leadership is not looking. Leadership must set out clear goals, measurements, and objectives. They must be continuously re-enforced and re-visited in various ways to demonstrate progress and positive impact.
  
• Have fun. A culture of friendliness, fun, and collaboration ensures everyone trusts each other, is willing to lend a helping hand, and enjoys coming to work. Smile, give high fives, and lighten up a little. :)

My beliefs for employees

I love managing teams, because I see each team member as another opportunity to positively affect someone's life. This list outlines a few of the key areas which I feel make work a special place for my employees.

I believe employees should...

• Feel empowered. Autonomy enables people and ideas to flourish without limits.
• Be challenged. Too easy is boring.
• Continuously learn. Mastery and feeling like you are growing in skills or knowledge is extremely rewarding.
• Have a purpose. Working on projects with meaning, significance, and positive impact.
• Feel safe to speak up. Open dialogue; all ideas are always welcome.
• Be creative. 100% planned = 0 innovation. Employees need space to have their best ideas come through.
• Understand why. See the whole picture and how work aligns to broader goals and strategy.
• Ask questions. No such thing as stupid questions. Challenge status quo.
• Leverage strengths. I believe in maximizing strengths, not zeroing in on development needs.
• Have fun. Smile, laugh, and be kind to each other. Work will not always be 100% fun, but it does not hurt to try. Why not have ice cream parties every Friday afternoon? :)

Creating the time to innovate -- Part II

I wanted to expand on my earlier post on creating more time. As I inherit or join new teams, the first deep-dive I do is an analysis on what people are spending their time on. The goal is to identify what can be eliminated, automated, or delegated to provide us time to do more impactful work.

Eliminate
I often tell folks, "Some parts of your role will be eliminated." I can sense fear in their eyes when I say that, so I quickly follow up with, "The goal is to eliminate the items which are not value-added work, so you have time to do more exciting and creative work."

The reaction I tend to get is no longer fear, but excitement, followed by a, "How...?"

The how is easier than you think. I propose taking an inventory of the work the team is doing, and assessing each item for its value and impact on the organization as compared to how much time is spent doing the task. It may become apparent some things which take a lot of time are not worth the value it is providing.

As an example, one team member told me each month for the past 2 years he worked on producing a set of reports for a particular group. It took him 2 days to compile the reports manually. I challenged him to identify if the reports are even being used or are still needed by that group. As it turns out, the reports were not being looked at any longer. He stopped creating the reports, and got 24 business days back each year.

Automate
Some things cannot be eliminated. Automate them.

Here are just a few items you should consider automating:

• Repetitive or common tasks
• Mindless items -- not requiring much human skill
• Anything considered a standard change (and if it is not standard, make it standard so it can be automated!)

The point is to let the machines do the work for you, so the team can focus on things which require more critical thinking and creativity.

Delegate

Having a single person be the sole holder of knowledge in a particular area can create bottlenecks. It means they may get pulled into urgent issues or other areas to help because no one else can. This is a time killer. They must spread their knowledge and delegate to others. 

Delegating can also occur in the reporting example I gave above. If those reports were still being used, perhaps the report creator could have devised a way for his business partners to view the details on their own. In other words, they can view or pull the reports whenever they needed without asking my team for help. An effective delegation.

Why be a great leader?

Great leaders have a tremendously positive impact on organizations. Here are a few reasons why you need to invest in great leadership.

A players hire A players, B players hire C players
It takes one to know one: great talent knows how to hire other great talent. In addition, great leaders know hiring people smarter than them is a good thing, and are not uncomfortable in doing so. They focus on hiring based on how results were achieved, and less on the "what."

Not-so-great leaders tend to hire sub-par employees, at times preferring those who will take orders and simply just do the job they tell them to do.

Great talent stays with great leadership
The immediate supervisor is the single best variable which can predict how engaged an employee will be. The number one reason why people leave their job is due to them not liking their immediate manager. A great leader helps retain top talent.

Great leadership has a trickle-down effect
Studies have found the effectiveness of leadership diminishes across the organization from top to bottom. Other words, the senior leadership on average is more effective than middle management, and middle management is more effective than lower management.

The key here is what the authors of the book How to Be Exceptional: Drive Leadership Success By Magnifying Your Strengths call the "leadership ceiling." If senior management is only average, then middle and lower management will be below average and significantly sub-par, respectively. Therefore, it is crucial to have an exceptionally strong senior management team, because their effectiveness sets the bar for the other levels of management.

Great leadership drives business results
From the same book above, the authors site a large study demonstrating sales leaders receiving the highest 360-degree feedback had 6 times the sales revenue as compared to the teams being led by the lowest-rated leaders. Top leaders pull out the best in people.

The bad words

Certain phrases are considered curse words on my teams. They represent the opposite culture which I try to instill. We strive for continuous improvement and innovation. We cannot settle or become overly comfortable, because technology moves at the speed of light. We must always be learning and thinking ahead.

Here are a few of those:

"That's the way we've always done it..."
Or also, "We've done it this way for years." If you hear this often, it generally means your team is probably far behind high-performing teams. Getting complacent or not having a constant pulse on improvement will eventually make your team irrelevant.

"Legacy system"
Why does this legacy system still exist? It is likely that managing it is painful, it contains critical security holes, and only a few employees understand it. Removing or upgrading it will reap many positive benefits. Quantify those, demonstrate the value, and kill the legacy stuff!

"Temporary code"
There is nothing more permanent than temporary code. We spend a little bit more time up front to get things right and not have to pay the price three-fold in the future (when things may break or require additional efforts due to earlier "shortcuts").

"Manual work"
We believe in automating everything. We want to be doing deep work tasks, letting the machines handle the trivial stuff.

Changing culture and creating the time to innovate does not come overnight, but demonstrating small wins along the way helps to reinforce the desired behavior.

The digital urgency

Software is disrupting business.

The days of stating things like, "We are not a technology company, we do X," are over. (Fill in your choice of traditionally non-tech domains for X: finance, farming, etc.)

Every company should have a digital urgency: a healthy dose of paranoia, knowing your business can be severely disrupted by a more nimble and tech-focused firm.

PayPal was not invented by a bank. Uber was not created by Yellow Cab. Blockbuster did not invent Netflix. Disrupters can come from anywhere and anyone.

If your leadership does not believe your company is a technology company, you must act fast. Otherwise your business may not exist in 5 years.

Here are some thoughts on how your company can stay relevant and use technology as a business driver.

IT is no longer a back-office function
Most great IT departments help deliver key business solutions which drive down costs, improve productivity and efficiency, enable scalability, and increase security. The continuous improvement mindset of great IT employees is something which is hard to teach, but exponentially valuable. Combine that with the "anything is possible with technology" attitude, and you have found a powerful digital engine that is capable of being at the front-lines of business decisions.

General Electric (GE), the traditional industrial juggernaut, is now a digital-first company. Their Predix platform helps power what they call the Industrial Internet. It enables asset and operations optimization by providing a standard way to run industrial-scale analytics and connect machines, data, and people.

Jeff Immelt, GE CEO, talks about how the GE Chief Information Officer (CIO) role has changed. Immelt recognized the amount of technical expertise GE had in-house, and combined the CIO's org (IT) with the engineering org (OT) to make a new Digital org driving revenue for the company through technology. Listen to his keynote address at GE's Minds and Machines conference where he describes their transformation.

External strategic radar
Every company should have a constant pulse on the external technology landscape: trends, start-up activity, etc. However, it needs to be structured. Thresholds should be created to know when the company should take action in a particular direction. When is a new concept really worth the investment? How early do we want to be on this trend?

The list of trends can be specific to your company's domain, but can also contain a few outliers that may not be initially obvious to how it may eventually fit into future plans. The list should be regularly monitored and reviewed at senior levels, and be visible to management at all levels.

Internal innovation: Hack Days
Autonomy is quite possibly the single most powerful "tool" for bringing about innovation and creativity from individuals. A Hack Day (or days) can further enable this.

Mentioned in my previous post about motivation, some companies, like Atlassian, give their employees the complete freedom to work on whatever they want for a short amount of time (24 hours each quarter, in Atlassian's case). They have seen new product ideas, enhancements, and other improvements come as a result of these.

I propose variants of this to see what works best for your organization. One variant might be to have an idea capturing tool used prior to a Hack Day, and participants can choose which of the top ideas they want to be a part of creating during the Hack Day itself.

The key is for management to be on board with giving their employees the time to do this. In addition, management must make this visible and regularly commit to helping fund or enable some of the best ideas to fruition. This is not a one-time event. This must become part of the culture.

In summary, the digital threat is real. The need for digital urgency is required from all levels of all organizations. Make the time to get the best out of your technologists, constantly monitor the external landscape, and enable creativity and innovation from within.

Multi-tasking and context switching

We all want our teams to be 100% utilized. Why hire someone if they only will be working 75% of the time?

As a result, many managers ensure individuals on their team always have a full plate of tasks to complete. However, the size of a task rarely is calculated with context switching costs in mind.

Context switching costs
Neurologically, our brains are not wired to be multi-taskers. The brain simply switches from one task to another rapidly.

That shift comes with a cost. Our brains take time to re-adjust and focus on the new task.

Some neurologists say 10-20% of the time a task takes to complete can actually be wasted through context switching.

Take a Java developer for example. They may have a lot of variable names, functions, API's to remember for a particular product. Moving to another product requires almost a clean wipe of their short-term memory, and a gradual ramp-up of the knowledge of the new project.

Therefore, the goal is not piling on many tasks to ensure 100% utilization. Rather, it is to improve productivity through reducing context switching.

Reducing context switching
Ultimately, working on one thing at a time is the most effective way to reduce context switching. Other tips to consider:

• Asynchronous communication -- When things are not urgent, writing an email, for example, may be better than an IM or phone call. This allows the individual to stay focused on the task and respond when they are ready.
• Setting aside time -- Following on the item above, emails can become a distraction. Dedicating a set block of time during the day for emails or other non-project related work can help keep focus high when doing project work.
• Set expectations -- Let your colleagues know at certain times you may not be quick to respond. This can help take pressure off you to feel the need to constantly check emails.

Agile plays a huge part in minimizing context switching from a software development perspective. More on Agile in a future post.

The Kanban approach is also useful here. It stresses the important of a work in progress limit. Each individual can only work on a certain amount of tasks each day. Any more than that is added to the backlog. All tasks are prioritized, so there is no slow-down to figure out what to work on next. Our DevOps engineer uses Kanban, and he has a work in progress limit of two. More on Kanban in the future, too.

MVP: failing fast is a good thing

How many times has your team had a scenario similar to the following example?

A senior client says a product cannot launch until one particular feature is added. Her reasoning: "No one will ever use this product unless this feature is included."

Although small in size, the feature is quite complex and would require another 2 months of development effort. The team works tirelessly those two months, and launches the product shortly thereafter.

A few weeks after go-live, the analytics demonstrate an unfortunate reality: while the product overall is getting good traction, no customers are actually using the feature suggested by the senior exec.

This scenario is exactly what Eric Ries' book, The Lean Startup, tries to address. In it he assesses how successful software development companies build and launch products.

Minimum Viable Product (MVP)
Ries describes the MVP as the product whose minimum set of features allow for learning from early adopters. Using the MVP, we are able to avoid building products no one wants, and maximize the learning per dollar spent.

The image below takes us through Ries' build-measure-learn feedback loop. An idea is formed and then built and released as an MVP. That MVP contains measurements or ways to pull data which we can learn from. From there, the product team is prepared to act on that data, and pivot or iterate.

Through small increments we can continue to test hypotheses and build a better product by minimizing the time through the feedback loop. If a particular feature or iteration is not successful, we learn early in the process through facts (analytics, metrics, user feedback, etc.).

This means failing fast is a good thing! Validated learning means we do not have to wait months before we find out no one will use a particular feature. We spend more time on things we know the users will want.

Image credit: Eric Ries, TheLeanStartup.com

Putting it into practice
I like to think of MVP as happening at each phase of the software development life cycle, in addition to the product viewed as a whole.

Take the design phase, for instance. Low fidelity mock-ups (think black-and-white, hand-sketched) are key because they speed time through "the loop." The goal is to get feedback fast -- how can you get fast feedback if you're spending time perfecting the shade of blue a button should be?

When it comes to the product owner's vision for features in release planning, how many of them build on top of an unvalidated hypothesis? What can be built and released quickly as an MVP instead?

Teams must be prepared to iterate. This means we cannot launch something and forget about it. We must release our MVP's, analyze the results, and pivot (move in a different direction vs. our hypothesis) or iterate based on our learning.

It is important to remember software has no value until it is in the hands of the user. The MVP approach gets more engaging software to the users faster by adapting incrementally.

Creating the time to innovate -- Part I

I am frequently approached by leadership from other divisions asking how my teams find the time to be so innovative. I propose that it is not finding the time, but rather creating the time. We all need more time in the day, but if you create a culture which inspires quality, you will naturally have the time you've been looking for.

Culture
A culture of continuous improvement runs through my team's veins. When inefficiencies arise, the team identifies solutions to improve productivity.

Team members are encouraged to give back to the team (I call this "team community service") by proposing and implementing better ways of doing things. Generally it's about 20% of their time (equating to about 1 day per week).

The key is not assigning tasks nor me saying what to do, but rather giving each individual a blank slate to identify and contribute to the areas they are most passionate about. (See previous post about motivation.)

Quality
Where do we get the time to implement these solutions? We have a constant pulse on things which prevent us from working on value-add tasks. From here we identify where we need to simplify or improve quality. These improvements in quality add up to very large time savings.

At first the team uses this extra time to catch up on value-add work and achieve a consistent flow. However, once we achieve optimal flow, we use the extra time gained to continue to innovate, gradually reaching the magic 20% time for each individual.

Suggestions to get started
Analyze your team's errors, production bugs, defects, and other distractions which require someone to stop what they're doing and spend time fixing issues. Use the 80/20 rule to determine the 20% of items causing 80% of the issues, and start to eliminate them.

It may be difficult at first, but leverage key team member strengths and passions. Some folks will not mind putting in extra effort, especially if it means helping the team in the long run and working on something they enjoy.

Be sure to track your team's progress. Take a baseline of key metrics today (number of production defects, average time spent fixing issues, etc.), and track improvements along the way.

The key is to have a tipping point in mind: when do you stop giving the time saved back to "business as usual" work and start giving it to "team community service?" Some individuals may only be able to reach 10%, while others may reach 20% or more.

You will see that 10-20% of time spent on innovation and continuous improvement will produce 2-10x gains for your team in the long run. Create the time to do it.


Update: Read Part II of this topic here.

What motivates us

Daniel Pink challenges the conventional way of thinking about motivation. He points to research demonstrating larger rewards do not necessarily lead to better performance for tasks involving conceptual and creative thinking.

So what does motivate us?

Autonomy
No one likes a micro-manager. When things are 100% planned it equates to zero innovation. Self-direction, on the other hand, drives engagement.

Software company Atlassian provides developers 24 hours once a quarter to work on whatever they want, however they want. The only thing they must do is show their results to the company at the end of the 24 hours. This quarterly event has produced many new products, bug fixes, and productivity improvements which may never have emerged otherwise.

Mastery
Why do people play musical instruments? I learned to play the piano after college, not because I was getting paid for it (I wasn't), but because I enjoyed doing it and seeing my progress along the way.

Open source projects are another example here (think Wikipedia or Linux). Contributors to these projects do not get paid, many already have jobs, but challenge and mastery spark their desire to contribute.

Purpose
We want to be a part of something bigger than ourselves. This goes hand-in-hand with my post about the power of "why."

Skype's founder said, "Our goal is to be disruptive, but in the cause of making the world a better place." That is quite a purpose to get up and go to work for every day.

It is important to note that money is in fact a motivator. If you pay someone too little, that can be severely de-motivating. Pay someone enough to get the issue of money off the table and they can focus solely on their work.

The power of "why" in leadership

Simon Sinek explains it's not what we do or how we do things that makes us a great leader; it's why we do it.

Sinek describes how our brains are hard-wired to follow those who believe what we believe. It is this connection which inspires others to take action, not because of what we're doing, but why we're doing it.

In the business world, great companies rally around leaders with big visions. Steve Jobs said he wanted to "put a ding in the universe" and go to bed each night saying "we've done something wonderful." Instagram set out "to change the way we see the world." These purpose-driven statements call on something more than just what the product is, or how it's made. They drive action through inspiration.

Sinek points out that Dr. Martin Luther King, Jr., gave the "I have a dream" speech, not the "I have a plan" speech. 

People don't buy what you do, they buy why you do it.