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? :)