One of the most important aspects of managing a successful technology organization is ensuring that you are practicing & instilling the concept of enablement at all levels. This concept applies to both the product/service you are producing and for people. A good example for your organization is enabling decision-making at the lowest levels possible. I have often seen this represented as “delegation” but I believe that enablement of decision-making is a more powerful concept than delegation which is driven from the top-down. I recently had the opportunity to lead a large infrastructure team and one of the first changes we made was breaking apart into reasonable sized PODs with the primary purpose of ensuring that decisions for the product & technology were driven from the bottom-up while guidance was flowing in from various stakeholders. Many teams practice a flavor of Agile but without enabling each POD to make the appropriate decisions you will run into organizational scalability problems.

The allure of IaaS & PaaS is firmly rooted in the concept of enablement. Self-service is an amazing if you are a DBA, developer or even the end user of your product. The cloud may not be suitable for your needs but don’t let that stop your organization from thinking strategically about bringing those processes & technologies “in-house” for scalability reasons. Implemented correctly, the infrastructure and platform you are building should enable the users and not hinder them, as is sometimes the case. Reducing the number of dependencies between technology teams for launching products is not only good for cycle time of product launches but also critical in scaling up.

Consider making enablement part of your technology team’s DNA and you will likely see that employee morale, productivity and other metrics like NPS will rise.

Driving big changes can be difficult in an organization and it can be especially difficult for new managers. Change is necessary and we should never be happy with status quo as our competitors and the overall market is changing around us. The larger the organization, the harder change can be. We touched on this in an earlier blog titled Five Leadership Lessons From Former Bosses but decided to dive into a little more detail this time. As a former manager of engineers and other talented technologists, I recall in my early days how I simply wanted to identify where we were headed with my team without giving them time to collaborate and provide input. On one occasion, we were in the midst of changing our PDLC to Agile. Agile was fairly new at the time so many didn’t understand the basis of it and in turn were resistant to using it. That problem is easily solved, right? I could just tell the team this is where we are going and this is how we are going to do it, now make sure you execute. And in a couple weeks time, poof, the change would be made and life would be good. After all, that would have been easy, right?

Although I didn’t say the words “get onboard,” I might as well have. I can tell you this doesn’t work well. My team was zapped. At that point they were no longer empowered and didn’t have any ownership of the change and when that happens a team’s performance will be suboptimal. Yeah, I could use the excuse that my senior management dictated what they wanted and I could drum up a bunch of other excuses but the fact of the matter is I should have raised a flag with my leadership and encouraged better collaboration for input from the engineers, QA testers, product managers, and others.

There were two key learning points that I was able to take away from my experience. Technology leaders should ask themselves two simple questions before they start to drive change in their organizations.

1) How do I make sure that my team has input and ownership of the change we are about to make?

Sit down with the team and work with them on coming up with solutions and their recommended timing. Engineers love to problem solve and they are very good at it. Provide the team with the problem that needs solved and any constraints and let them determine the solution. For example, in the situation I described above, we needed to improve our time to market. Many products and features across the organization were being delivered late, payloads for deployments were too big, and the business was frustrated. As on overall company we decided that we would adopt Agile utilizing Scrum practices but there were still many problems that needed to be solved. Those included determining a branching strategy, determining a deployment strategy, identifying how to measure a sprints performance, and many others. By providing the context of why changes need to be made, the team will recognize the significance of their input and by allowing them to come up with solutions they will feel empowered and have ownership in the game. All of this will help you to create a higher performing engineering team.

2) What do I need to do as a leader to establish guardrails in my organization and sustain the change as my company grows?

Once the team has determined how to solve some of the problems, you will want to make sure that you sustain them in your organization. To do this, work with them to establish documented guardrails or principles that be used as the what. For example, the Agile Manifesto essentially identifies principles that you can use. One principle could be “Business people and developers must work together daily throughout the project.” This describes a behavior that’s needed but doesn’t identify how. The team can decide the specifics on how they will achieve the principle. We at AKF believe in establishing architectural and scaling principles that are essentially guardrails as well. (Visit our earlier blog on architectural principles for more details.) For example, Rule Number 39 – Ensure You Can Wire on and Off Functions in our book Scalability Rules identifies the need to have a framework where you can quickly disable and enable features to minimize impact to customers when a failure occurs. You can solve this many ways and your engineers can determine what the solution should be. Once your principles are established you should monitor them to make sure they are being upheld and reward results.

If you ask yourself these two simple questions before diving into a big change your road to success will be much easier. Now that you have empowered your team to determine how to solve the problem and you have documented your principles and guardrails, the team should be able to operate within them and make decisions on their own. In turn, you will find that they feel empowered and you will have helped to create and maintain a higher performing team.

It is difficult – research shows nearly impossible – for any of us to accurately answer the question of “What makes us successful?”

At the intersection of cognitive biases (especially attribution bias) and the Dunning-Kruger effect lies this (to my knowledge unnamed) phenomenon that keeps all of us from understanding how our contributions might have resulted in a successful outcome.  Cognitive biases cause us to take far too much credit for successes, and incorrectly attribute the reasons for our success.   The Dunning-Kruger effect causes us overrate our abilities to achieve similar success in the future.   All of these work against us in trying to determine what allowed us to be successful.

Incorrectly attributing the causes for our success can be a huge problem.  Imagine that you decide that the reason your company achieved a particular successful outcome is because of your sales ability as a senior executive.  You might be inclined to believe, based on your personal analysis that your sales ability and sales execution will result in similar future successes.  There are two potential problems here.  The first is that we  incorrectly attributed the reason for success when the real reason was due to, for instance, the efficacy of our product.  The second is that we overrated our contribution and abilities when the real credit should go somewhere else.   Clearly both can lead to future disasters down the road.

You may be thinking that many people are successful time and time again by taking similar actions and by employing similar behaviors.  That is absolutely true.  The issue is not whether we can repeat our past successes – it’s that we can’t accurately identify (for ourselves) which actions or behaviors led to those successes.

Research suggests that we are much more likely, if we apply disciplined process, to learn from failures as compared to successes.  Even greater learning can be gleaned from comparing our successes and failures.   Furthermore, involving others helps us triangulate and either validate or invalidate our beliefs as to the causes of both successes and failures.  The key here is disciplined process coupled with introspection and outsider perspective to guard against cognitive bias and eliminate the Dunning-Kruger effect.

In summary:

1)      We are ill equipped to identify the causes of success without outside help.

2)      We are better equipped to identify the causes of failure.

3)      We are best equipped to compare successes and failures and draw conclusions.

4)      It is always best to involve multiple people in the identification of either success or failure.

Over the past 16 years I have had a chance to work for more than 12 different bosses. While some have been better leaders than others I’ve tried to learn from each of them. Below are five leadership lessons that I’ve picked up from them and subsequently been able to use with my teams.

• Retain Talent – Go out of your way to retain your good people. Make it personal and include the family when possible. One of my star players shared with me that she had dinner plans with her husband for their anniversary. I called ahead to the restaurant and bought them a bottle of wine with the message “Happy Anniversary and thanks for all of your hard work.”
• Success Metrics – Use team success metrics to motivate your team and create a strong culture of driving to success rather than some arbitrary stopping point like a release. As we’ve written about before don’t confuse product releases with success. Identify and start to measure business metrics that the team can understand and rally around. Determine what to measure based on the drivers of revenue and cost of your business. Share these metrics with your organization and celebrate success and dig into areas where you are falling short to identify a get-well plan.
• Guiding Principles – Empower your team with guiding principles that help them to make day-to-day decisions. Similar to architectural principles, guiding principles empower your team or organization to make decisions on their own. Have the team help develop them and make them visible. Revisit them on a regular basis. This especially helps during times when you need to drive mindset change. You will be surprised at the questions and conversations that come up as you drive to calibrate on mindset shift.
• Poor Performers – Do not ignore your poor performers. Use these three axes to evaluate employees performance. If the problem is performance, attempt to help the employee by coaching and mentoring. If the problem is behavioral or if they don’t respond to coaching, you need to manage them out quickly. Depending on your organization, it may be difficult to manage poor performers out but this is not an excuse to ignore it. Poor performers can be a drag on the team, poor behaviors can be cancerous. And don’t forget they are a reflection of your work as well.
• Feedback – Give feedback to your team members frequently and in real time. Don’t wait until the annual review to give feedback. Gen Y and Millenniums are more accustomed to instant feedback and communication. That means you may have to adjust your style as you work to coach and guide your direct reports. Utilize all available communication medium to praise. Send them an email recognizing them for their actions and tie it to the positive impact it had on the business or the team. Leave them a voice mail. And of course the good old fashioned in person or one by one conversation works well. You will soon seen the positive motivation you inject into your team.
• Business Knowledge – Understand the business. The only way for you to be successful is to be able to speak and work with other business executives, which means you need to make the effort to understand their roles. Block off your calendar to sit with peers to see what they do on a day-to-day basis. The path to a CIO/CTO role is by being a great partner to the business.

Hopefully you can use some of these with your teams or at least make you aware that you should periodically look back for lessons learned. Often these lessons learned make great one-on-one topics for junior managers interested in improving their leadership.

It seems that nearly everyone is jumping on the bandwagon to highlight the leadership lessons we should learn from Steve Jobs’ business success.  A particularly well written piece is Walt Isaacson’s summary in HBR of his incredible biography of Jobs.  But let’s face it, if we are truly introspective and rational we can probably agree that none of us have Steve’s product vision and sense of the market.  As such, we have as many things to learn from what he did wrong as what he did right.  I for one stand in absolute horror and dismay at his approach and overall attitude and am amazed that he was capable of overcoming his many personality and leadership shortcomings.  Here are a few lessons derived from Steve’s shortcomings:

Don’t be a Brilliant Jerk:   I wish I could claim that I dreamt up this term, but it comes from Reed Hastings.  After reading Walter Isaacson’s biography of Jobs, I can’t help but think that Jobs was a jerk his entire life.  He screwed over his friends from the start of his early career, such as when he used Wozniak at Atari for his own personal gain.   He would cry when he didn’t get his way, and scream at those who didn’t agree with him.  There simply is no room for this type of behavior if you want a truly high performing team.  Maybe you can get away with it if you truly are the next Steve Jobs – but you probably aren’t.  And even if one of us is the next Steve Jobs, the real question we all should ask ourselves is “How great would Steve Jobs have been if he had treated people with compassion and respect?”

Walk the Talk:   Steve would eschew certain perks like a private parking spot and then park nearly every day in the handicapped parking spot.  What kind of jerk does something like that?  You are much better off taking the private space than pretending to be egalitarian and then deciding to violate the rules whenever it suits you to do so.  The people you lead will see that your actions don’t match your statements.  That in turn just makes you another pompous stuffed shirt.

Don’t Steal Your People’s Ideas and Accomplishments:   Great leaders inspire their teams to accomplish great things.  Few things are as deflating to team morale as stealing the ideas and accomplishments of the team and representing them as your own.  Isaacson’s book has plenty of examples where Jobs did just that, and it is clear from the reaction of the people that they felt slighted.  You will always get credit for team accomplishments even if you don’t try to do so.  You are better off ensuring that the folks who truly contributed to the accomplishment get recognized appropriately.  On the flip side, you should always take the blame for team failures – it is part of your job.  That’s not to say that you shouldn’t turn around and coach, develop or fire those who did not perform – you should.  But you can never delegate accountability and you are ultimately accountable for each and every failure.

Use Data and Evidence:   Steve apparently had a number of quirks.  He thought, at one point, that eating an apple (or fruit) only diet would keep him from having BO.  He unfortunately believed, with very little data or evidence, that special diets might help him in his fight with cancer without surgery even when friends and medical professionals urged him to have an early low risk surgery with a high rate of success.  There is no doubt that Steve had great intuition in certain areas such as the development of high tech products.  But as the Dunning-Kruger effect tells us and as Steve’s unfortunate choices show us, we are terrible at identifying where we are great and where we aren’t – or where our intuition is great and where it is not.  As a result, relying on our intuition when data exists that can guide our approaches is a recipe for disaster.  At the very least, data can be confirmatory and even better it can just show us the right answer or path.  Always remember that what matters most is success.  The need to be perceived as being right is for egotistical jerks; the need to get great results is a fiduciary responsibility.  The easiest way to get great results is to rely on great data to help drive great and timely decisions.

One of the most difficult things to do as a manager is to properly evaluate employees. The difficulty stems from many factors including one of the most fundamental – what aspects should you evaluate? We believe there are three fundamental aspects upon which you should evaluate all employees. These are performance, behavior, and potential. As shown in the AKF Employee Evaluation Cube below each of these factors are independent and in total make up the overall rating of the individual. Individuals who excel in all three are truly superior employees. Let’s first consider why we choose these three aspects and then we can discuss ratings in each quadrant.

Evaluation Aspects
Performance - employees in every role must achieve their goals. Assigning these goals to employees should be done via the AKF Goal Tree as discussed in Chapter 5 of The Art of Scalability. One strategy for evaluating individuals against their goals is to have them first rate themselves (0-10) on achieving their goals and then the manager should rate them using the same scale. By doing this you allow the employee to spend time thinking about their own performance prior to hearing their manager’s rating. This is also a great starting point for a conversation about where the two ratings are discrepant. Should you start by presenting the manager’s rating the employee might not be prepared for the conversation.

Behavior - this is the most important aspect to evaluate. Employees who perform really well but don’t behave in a manner that is in line with the corporate culture must be let go. You cannot have employees who don’t have the same beliefs, morals, and culture as the company does. We often see employees who are great performer but don’t fit within the company described as ‘brilliant jerks’. These individuals might be great for a three person startup but they will destroy the moral and productivity of larger teams.

Potential - as a matter of course you should periodically evaluate the potential of employees to take on more responsibility. Individuals who are superior performs usually have greater potential and will be interested in bigger challenges.

Ratings
We often use the terminology that we picked up from GE for rating employees – A, B, and C players. An A player is someone who meets or exceeds expectations on all aspects – performance, behavior, and potential. You can also make an argument that A players can be superior on performance and behavior but limited on potential…not all our A players need to be promotable.

B players are employees who are under performing but demonstrating great behaviors. With some coaching these employees are expected to be A players. This might be a new employee, junior employee, or someone in a new role. While they are demonstrating behaviors in line with the company they need more time or help with meeting their goals.

C players are ones who are either demonstrating bad behaviors (regardless of performance) or who despite coaching have not been able to meet their performance goals. If an employee isn’t a great cultural, behavioral, or moral fit they must go.

No matter how many lines of code we’ve coded or architectures we’ve designed, we occasionally get push back on changes we suggest. Usually this comes in the form of a statement such as “oh, that’s just a simple matter of programming, huh?” For those uninitiated, a Simple Matter of Programming (SMOP) is a phrase used to ironically indicate that a suggested feature or design change would in fact require a great deal of effort implying that the person proposing the feature underestimates its cost. We occasionally joke with teams about how long a change will take but we admittedly don’t know the system well enough after a couple days to provide estimates. Even teams with great engineers get estimates wrong more often than not. However, what we do know from lots of personal experience and having worked with over two hundred companies, are orders of magnitude and what things should be considered difficult and what things should be easy.

It is common for a company to think that splitting their systems into swim lanes or partitioning by the Y or Z axes would be incredibly difficult until we walk them through the logic of how to make the changes. Certainly these logical steps are a far cry from actual code changes but most of the time companies “get it” and before the day is over start agreeing that the changes are reasonable.

An exception to this occurred recently where a non-technical manager made the obligatory SMOP comment and then continued to resist our suggestions on how the changes might be accomplished. The engineers in the room “got it” and you could see them nodding in agreement about how changes could be made but the business leader refused to acquiesce. In the end this organization will not make the necessary changes to scale and will likely limit their future value because of this.

To me this makes the point about mindset. I learned during college that I could convince myself that a subject matter was easy and I could learn it quickly (programming) or that it was impossible and I was no good at it (foreign language). The difference wasn’t the difficulty of the subject matter but rather my mindset regarding each topic. Your organization is the same way and if you’re the leader, your teams take their cues from you about how easy or hard something is going to be. This isn’t a recommendation that non-technical business leaders make estimates for feature development but rather that you maintain an open mindset about situations and challenges. Sometimes the greatest revelations come from the darkest hours and what seemed impossible was a key differentiator that made all the difference.

Resist the urge to SMOP someone’s idea and be open about changes. Approaching things as an individual and an organization with an open mindset will benefit you immensely.

Motivated employees are great but inspired employees are even better. You might not have thought much about the difference between motivation and inspiration but it could be well worth a few minutes to do so. For the formal definitions we turn to the dictionary:
inspire – to exert an animating, enlivening, or exalting influence on
motivate – to provide with a motive (something that causes a person to act)

While not exceptionally helpful these definitions do offer some insight into the differences. Inspiration is described as an influence that is “animated, enlivening, or exalting” while motivation is described as just something that causes one to act. Lots of things can cause someone to act including fear, disgust, hatred, love, hunger, etc. Would you rather have an employee who is acting out of fear or because of an exalting influence? I know which one I would prefer.

Before we tackle the question of how to inspire someone, let’s discuss how people try to motivate employees. As a young manager, I was taught that people are motivated by one of five things: achievement, respect, responsibility, advancement, and growth. However this list isn’t at all complete. As we discussed above, people are motivated by lots of other negative things as well as the positive things in this list. More importantly, motivations are short lived. The excitement over a potential pay increase, a better title, or even fear of losing your job can only last so long before we become immune to them. Think of walking into a room and smelling a strong aroma but in a few minutes our olfactory sense becomes accustom to the smell and we stop being aware of it. The same goes for motivations. Inspirations on the other hand are much longer lasting.

When an employee is inspired, they are working for a cause, they believe in the mission, they have a higher calling. The word inspiration from its origin means “breathed upon.” In Greek mythology there are muses responsible for inspiration but there are no such equivalents for motivation. The way we inspire employees is to make them feel part of something that is bigger than themselves. Treat your employees like team members, tell them why the work they do is important, and share with them your passion. Work on inspiring your employees instead of just motivating them and you’ll have better results that last longer.

In this third installment of our “Agile Organization” series we discuss the qualities and attributes necessary for someone to lead a group of cross functional Agile teams in the development of a web-centric product.  For the purposes of this discussion, the Agile Executive is the person responsible for leading a group of agile teams in the development of a product.

In a world with less focus on functional organizations such as the one we’ve described in our Agile Organization articles, it is imperative that the leadership have a good understanding of all domains from the overall business through product management and finally each of the technical domains.  Clearly such an individual can’t be an expert in every one of these areas, but they should be deep in at least one and broad through all of them.  Ideally this would have been the case in the functional world as well, but alas functional organizations exist to support deep rather than broad domain knowledge.  In the Agile world we need deep in at least area and broad in all areas.

Such a deep yet broad individual could come from any of the functional domains.  The former head of product management may be one such candidate assuming that he or she had good engineering and operations understanding.  The head of engineering and operations may be heads of other agile teams, assuming that they have a high business acumen and good product understanding.  In fact, it should not matter whence the individual comes, but rather whether he or she has the business acumen, product savvy and technical chops to lead teams.

In our view of the world, such an individual will likely have a strong education consisting of an undergraduate STEM (science, technology, engineering or math) degree.  This helps give them the fundamentals necessary to effectively interact with engineers and add value to the engineering process.  They will also have likely attended graduate school in a business focused program such as an MBA with a curriculum that covers finance, accounting, product and strategy.  This background helps them understand the language of business.  The person will hopefully have served for at least a short time in one of the engineering disciplines as an individual contributor to help bridge the communication chasm that can sometimes exist between those who “do” and those who “dream”.  As they progress in their career, they will have taken on roles within product or worked closely with product in not only identification of near term product elements, but the strategic evaluation of product needs longer term as well.

From the perspective of philosophy, the ideal candidates are those who understand that innovation is more closely correlated with collaboration through wide networks than it is to the intelligence of one individual or a small group of people.  This understanding helps drive beneficial cognitive conflict and increased contribution to the process of innovation rather than the closed minded approach of affective conflict associated with small groups of contributors.

In summary, it’s not about whence the person comes but rather “who the person is”.  Leading cross disciplinary teams requires cross disciplinary knowledge.  As we can’t possibly experience enough personally to be effective in all areas, we must broaden ourselves through education and exposure and deepen ourselves through specific past experiences.  Most importantly, for a leader to succeed in such an environment he or she must understand that “it’s not about them” – that success is most highly correlated with teams that contribute and not with just being “wickedly smart”.

Having discussed why organizations arranged along functional boundaries (e.g. production or engineering, operations, infrastructure, QA, etc) and multi-disciplinary Agile teams are often at odds and counterproductive, we now propose a method of organizing product teams more aligned with the Agile process and Agile methods.

The potential solution is really very simple.  The design goals behind the solution are: maximization of individual capabilities of any given team to quickly and efficiently create solutions and solve problems; creation of ownership of individual products (or portions of products) and the business success metrics associated with that product in order to maximize innovation; maximization of morale through a sense of ownership and delegation of decision making; and reduction in time to market through the elimination of non-value added conflict.

The solution is clear given these goals – eliminate functional organizations and align the organization to architecture specific services.   In the ideal case, each of the senior leaders of these organizations are capable of owning and leading one more complete agile teams.   The number of teams that an executive has is likely going to depend on the size of the company, the size of the engineering and product teams and the number of discrete services in the company’s product architecture.

Here we come to a very important point – it is critically important that the architecture, the process and the organization structure be aligned to reap the benefits of such a change.  If the product architecture continues to be monolithic, nothing is solved.  The solution described above will get you no further than an “agile overlay across functional organizations”.  Each division of agile teams needs to own their own services so that disputes, problems and opportunities can be resolved or capitalized within the team.  This rapid resolution starts to slow down when outside resources are necessary to resolve a problem or capitalize on an opportunity.

We readily admit that this new approach to eliminating functional organizations in favor of agile teams isn’t for everyone.  Some companies don’t have the need to segment their architectures into services as they aren’t experiencing rapid growth.  As such, they shouldn’t pay the price of re-architecting their product.  Some companies deliver to very clearly defined specifications and as a result can’t really benefit from the product discovery aspects inherent to Agile or the questionable “final dates”.  These companies are probably better off continuing to develop in a waterfall fashion.  Many companies won’t have the right skill sets at the top to have former functional executives own product sections.

This last issue sets up a topic for another post.  The question we aim to answer is “What are the qualities and attributes of the Agile Executive?”