AKF Partners

Abbott, Keeven & Fisher PartnersPartners In Hyper Growth

Category » Leadership and Management

More Leadership Lessons from Steve Jobs

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.


2 comments

How to Evaluate Employees

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 morale 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 performers 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.


Comments Off on How to Evaluate Employees

An Open Mindset

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.


4 comments

Inspiration vs Motivation

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.


Comments Off on Inspiration vs Motivation

The Agile Executive

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”.


Comments Off on The Agile Executive

The Agile Organization Solution

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?”


Comments Off on The Agile Organization Solution

The Agile Organization

We’ve done a lot of work with organizations attempting to become more Agile by implementing Agile development practices.  One common problem we see time and time again is that the “old school” way of defining organization structure starts to lose its value in an Agile world.  Here I am specifically talking about organization structures developed around functional roles such as development (or engineering), QA, Operations, Infrastructure, etc.

This old method of organizing, which resembles a Y axis split within the AKF scale cube served our industry well for a long time.  And, for many organizations, it can continue to work well.  It particularly works well in organizations that follow waterfall models as the organization structure mimics the flow and passage of work through certain gates.  The structure is also comforting in its familiarity as most long tenured managers and individual contributors have worked within similarly structured organizations their entire professional careers.

But in the Agile world, this organization structure doesn’t add as much value as in the Waterfall world.  In fact, I argue that it’s counter-productive in many ways.  The first and perhaps most benign issue is that the actual structure of the organization does not foster work-flow.  Unlike waterfall development where one group hands off a project to another in phases (development to QA, QA to operations, etc), Agile methods seek to develop and deploy seamlessly.  To be successful the Agile team needs representation from multiple stakeholders within functional groups.  As individuals now spend most of their time in cross functional teams, what value does the functional group offer?  In essence, these functional organizations become the analog to the “home room” in school.

The next problem is the inherent conflict created between the Agile team and the functional organization.  To be truly effective, the team must be empowered to some degree.  What power or responsibility does the functional leader then have?  If he or she isn’t responsible for a specific product, are they to be given some sort of veto power?  Such a notion has meaning in the waterfall world but really runs counter to the time to market and discovery objectives of Agile methods.  The resulting affective conflict simply doesn’t add value to the overall product.  In fact, as research shows, it destroys value.  Some proponents of continuing with functional organizations might indicate that the functional groups allow for more effective management and mentoring of individuals within their domain.  Given how little time managers truly spend on mentoring relative to other tasks, I highly doubt this is the case for most organizations.  Our experience is that the functional groups spend more time arguing over ownership of certain decisions (affective conflict) rather than mentoring, training and evaluating individual contributors.

Perhaps the largest problem – larger than the lack of support for work flow and the creation of conflict – is that implementing agile processes across functional organizations sub-optimizes innovation.  Research indicates that innovation happens most frequently and beneficially within groups of individuals with diverse and non-overlapping experience across a number of domains (functional and experiential diversity) and with non-redundant links to individuals outside of their organization.  By engaging in beneficial debate (cognitive conflict) on approaches to a certain problem or opportunity, the perspective and networks brought by each person widens the potential solution set.  Alas, this is the true unheralded value of agile development teams that properly incorporate multiple disciplines within the team (QA, dev, product, infrastructure).  Each of these individuals not only brings new and valuable expertise in how to develop a product, they also have contacts outside the organization unlikely to be matched by each of their peers.  Innovation quality and frequency therefore increases.  But the inherent conflict in multiple competing organizational affiliations will dampen this innovation.  So not only is there conflict and a lack of workflow, the potential major benefit is removed or at the very least diminished.

Having discussed the problems inherent to functional organizations and agile processes, we’ll next discuss how a company might “organize” around agile to be more effective.


1 comment

Corporate Mouth Diarrhea

It’s been awhile since I’ve gone on a rant. Leaving my rants bottled up inside me just means that I’ll take it out on my partners in some fashion (most likely by hiding in their houses and beating them upon entry in the fashion of Cato and the Pink Panther) .   Chief among the things that are ticking me off right now are some ridiculous phrases and approaches to speech that I will term “Corporate Speak”.  This mouth diarrhea is closely related to the “buzzword bingo” games of the mid 2000’s where employees would wait for half retarded executives to flip clichés out at company meetings.   Unlike buzzword bingo, this dribble simply doesn’t seem to have a purpose and we should try to excise it form our speech like the tumor that it is.  Candidly speaking, my partners and I are guilty of some of these ridiculous statements and we are working actively with a speech oncologist to send them into remission.  One warning: if you are speaking about yourself in the third person you may be beyond help.  Third person speech is a clear indication that you should just end your career.

Without further ado, here are the most cancerous phrases:

Phrase Intent of Phrase Real Meaning 

“To your point…” I’d like to give you credit for saying the following… I’m going to say something I want you to agree with and I’m a tool. 

.

“Put on your CEO hat for a minute…” (or some other position hat) I would like you to think across all functional and business unit areas rather than just your own. I don’t agree with you – just change your opinion to how I think.  Oh, and I’m a tool too. 

.

“From a shareholder’s perspective…” or “Let’s put on our shareholder hat for a minute…” Let’s think about what shareholders care about I don’t agree with you and I’m going to pretend the shareholders don’t either.  The shareholders probably think I’m a tool. 

.

“This is best in class…” or “This is world class…” or “This is a best demonstrated practice…” Good job for achieving excellence. What you are doing makes me look good or makes my job easier – congratulations.  By the way, I’m a tool. 

.

“Ask yourself what Marty would do”.  Any reference to oneself in the third person Anyone speaking in the third person (referencing him or herself) is making themselves feel important Who knows – this is just a ridiculous practice.  Nothing yells I’m a tool bigger than this one.  You might as well scream it from a clock tower. 

.

“Let’s level up” or “Let’s look at this from a 30,000 foot level” We need some overall context to make this meaningful and make appropriate decisions I’m not comfortable with details and don’t want to look like an idiot, or I don’t agree with where this is going – I’m going to change the direction.  Have I told you I’m a tool? 

.

“I think you have a valid point, but…” Interesting and valid, but one of many potential explanations or positions. I don’t agree with you so let me tell you how we’re going to do it.  Guess what?  I’m a tool. 

.

“I would say…” or “I would tell you that…” I have no idea what the intent of this opening is – this is just a weird, stupid saying. I’m too much of an idiot and a tool to just tell you what I think without a lame qualification 

.


Comments Off on Corporate Mouth Diarrhea

11 Leadership Principles – Part II

This is a continuation post from last week where we covered the first six leadership principles from the perspective of a technology leader. In this post we’ll cover the remaining five principles.

7) Keep your soldiers informed – In the military the headquarter staff makes an overall plan for a mission, presents the plan to subordinate units, and lets them plan the details of how to execute. This planning hierarch can occur across many levels such as starting from the Division HQ, then to the Brigade HQ, then to the Battalion HQ, then to the Company, the Platoon, and finally to the Squad. All this planning takes time but each subordinate plan requires information from the higher plan. You can imagine that with all this planning you could quickly run out of time to actually perform the mission, assuming it is time sensitive, which most things in life and business are. The rule of thumb that we used as a staff in the military was to take 1/3 of the remaining time to put your plan together and leave 2/3 for your subordinates. If we the Division staff had 1 week prior to the mission they would take 2.3 days to develop their plan, leaving 4.7 days remaining. The Brigade would use 1.5 days, leaving 3.2 days. The Battalion would use 1 day, leaving 3.1. The Company would use 0.7 days, leaving 2.1, the Platoon 0.5 day, leaving 1.4, the Squad 0.3 day, leaving 0.9. This same concept should apply to your teams. Don’t sit on ideas, contracts, or problems for 3/4 of the time before it is due and make your team scramble. Give your teams the majority of the time to plan and execute. Reiterating from principle #3, make sound and timely decisions. Taking up all the time so that you get 95% of the information before you make a decision is being a whimp. Gather the most pertinent data, make the best decision and make sure your team gets as much time to react as possible.

8) Develop a sense of responsibility in your subordinates – This principle is a combination of #2 “Seek responsibility and take responsibility for your actions” and #4 “Set the Example”. If you seek responsibility for your actions and set the example for your team, they will follow and behave the same way. For a technology leader, this might manifest itself in a situation where you expect your subordinates to admit when they changed the production environment without approval resulting in an incident. You should expect and demand this behavior from your team but you first must ensure that you are’re taking responsibility for your own actions. Instill in your team a sense of ownership over the site. In order to do so you need to set the example of owning the business. Blaming the business leaders for poor decisions and expecting your team to take responsibility for the technology will never work. Create a culture where people want to own their areas and do so by owning yours.

9) Ensure that the task is understood, supervised and accomplished – There is a big difference between micromanaging and providing adequate guidance on a project. Per principle #2 “Seek responsibility and take responsibility for your actions”, you can’t delegate your responsibility only your authority. Miscommunication is probably the single biggest cause of rework. Clear, concise, articulate criteria are the way to ensure tasks are started properly and accomplished. If you assign an unclear task without a deadline and without guidance on resources you can expect it to come in over budget, after the deadline, and not accurately completed. Communication of the task is your responsibility. In military aircraft we used a three-way positive transfer of control. This meant that if I were flying and I wanted by co-pilot to fly I would say “you have the controls”, they would respond with “I have the controls”, and I would reiterate “you have the controls.” This way there was very little chance of no one actually flying the aircraft…which in tandem seat aircraft you’d be surprised how easy that can occur.

10) Build the team – As a leader you must be constantly building the team. This doesn’t always mean hiring more engineers. Building the team can take the shape of improving their skill sets or replacing underperforming individuals. We’ve written before about seed-feed-weed-succeed. This simple garden analogy means that you need to hire (seed) the team with great players, grow (feed) them through challenging projects, greater responsibility, and training, get rid of (weed) underperformers once they’ve had a chance to improve, and by doing these three things well you and your teams will succeed.

11) Employ your unit in accordance with its capabilities – This last principle requires that you first follow principle #5 “know your soldiers and look out for their welfare.” In order to deploy or ask your team to take on certain projects, you need to first know what their capabilities are as a team and as individuals. If your team is newly formed, you probably don’t want to take on critical projects for major customers. If you don’t have anyone who knows databases you don’t want to architect a DB heavy application. Setting your team up for failure is not what leaders do but you won’t know if you’re doing that unless you know your team and the team members.


Comments Off on 11 Leadership Principles – Part II

11 Leadership Principles – Part I

In several previous posts, I’ve referenced a set of 11 leadership principles that I was taught in the military many years ago. These are apparently still in use by the Marine Corps and studied by the Air Force. As appropriate as they were for leading small units, they have also served me well in many other roles. No doubt you’ll quickly see the relevance these principles have to a military leader but to a technology leader you might balk. In this post I want to cover them using the lens of a technology leader. I think they are extremely relevant to all leaders and might help you either improve yourself or coach a rising star in your organization. I’ll start with the first six this week and finish up the remaining five in next week’s post.

1) Know yourself and seek self-improvement – In no other discipline, that I can think of, are practitioners and scholars faced with more rapid change than information technology. Not only is the underlying technology rapidly changing and sub-disiplines, like scalability, evolving but entire business models are being made obsolete to make way for new models. As technologist, we must all constantly improve and the first step down that path is to know your own limitations. Too often we run into technologist, usually men…but that’s another post, who think they know everything there is to know. Even if that were true this morning by tonight they would be behind in their knowledge.

2) Be technically and tactically proficient – I’ve covered this several times before in other posts but its worth repeating. To be a great technology leader you need to understand the technology. Your team will respect your opinions more and you won’t have to run back to your architect to answer questions raised by your peers. If you don’t know how to code or setup a database or haven’t done it in a while, start this weekend on a project that will require you to learn hands on about your chosen profession.

3) Seek responsibility and take responsibility for your actions – There is a passage in The Art of Scalability that reads “You can delegate anything you would like, but you can never delegate the accountability for results.” I can’t think of a more concise way to say this, you as the leader are responsible, period…end of the story.

4) Make sound and timely decisions – We are proponents of data driven decisions and have seen many times in our careers where someone’s world-class opinion about a product feature turned out to be completely wrong. However, analysis-paralysis occurs every day, even in small startups where you would think there wouldn’t be such an issue. Use the Pareto principle. Gather the 20% of information that makes 80% of the impact, make a decision and execute. The entire point of the Agile methodology, that almost all technologist are fans of, is to admit that we don’t know. The correct way to get there isn’t thinking long and hard about stuff but rather make things happen and see the results in order to make course corrections for the next iteration.

5) Set the example – You’re probably familiar with the proverb that a fish rots from the head. Organizations, whether government, monarchies, military, or tech startups, are the same. A leader who lies or has a poor work ethic will quickly have a team that imitates their shortfalls. Arrive earlier, leave later, work harder. Show more passion, more grace, and more thankfulness for your employees. Act like the leader you want to be led by and you’ll have an amazing team that will follow you anywhere.

6) Know your soldiers and look out for their welfare – Similar to the principle above, in order to led well over the long term, you need to build a relationship with your team by getting to know them and letting them get to know you. I’m incredibly private and reserved but you have to open up some in order to let peers and subordinates know that you’re human. Once you know your team members, their capabilities, their fears, their hopes, their dreams…look out for them. This means helping them become the manager they want to become or help them earn the promotion or pay raise they desire. Put them in positions that will stretch them but don’t leave them hanging without a safety net. A good leader gives team members opportunities to succeed or fail. A great leader puts team members in positions where they can succeed or fail but makes sure they catch them if they fall. I relate this to teaching a child how to ride a bike without training wheels. If the child feels you holding them they don’t build the confidence they need to do it themselves. If you don’t keep a close hand they might fall and hurt themselves, which will make them shy away from wanting to learn. The perfect combination is far enough away to make them feel like they could fall but close enough to catch them.


1 comment