The Importance of Leadership - My Leadership Style

A lot of people have asked me why I decided to make the leap into management.  I was a fairly successful programmer having working my way up through the ranks from Junior Developer to Solutions Architect.  I prided myself on being a quick study and having an ability to contribute to a project almost immediately and continuing to be a go-to resource for years to come.  Unfortunately, I often saw that the leadership of the company lacking.  I felt the focus was often on the wrong things at the wrong times.  And the saying that people are promoted to incompetence had a ringing of truth to it.  There are lots of different types of leadership and they all have their place.  However, if the leaders don't do some of the basics, problems can quickly arise.

Here are some items that I consider extremely important for a leader:

1. Have a vision
2. Be future thinking.
3. Set the direction to meet the vision
4. Stay out of the weeds (50,000 foot view)
5. Balance the needs of customers with the needs of employees.
6. Recognize that change may be needed.
7. Keep Finger on the Pulse
8. Support the Team
9. Assess Self

Have a vision
Having a vision and effectively communicating it is one of the most important aspects of effective leadership.  It is arguably the single most important job of leaders.  Without it, the rest of the organization cannot execute effectively.  It is also important to note that Vision should remain relatively stable.  It takes time to execute on a vision, so if it is constantly changing/shifting it will lead to frustration and an inability to execute effectively on.

Be Future Thinking
It is easy to be focused on the here and now, but a good leader is also preparing for what comes next.  Products need to be developed, tested, deployed and to be successful you need to able to do that regularly.  By no means should a leader lose sight of the day-to-day activities required to execute.  However, true leaders should empower and trust the people under them to do the job they were hired to do.  It is important to spend the significant amount of time needed to prepare for the future so the organization can operate with a cadence that allows for a timely release to market.

Set the direction to meet the vision
Understanding what is comes next to execute on the vision is just as important as understanding the vision in the first place.  There are almost always multiple steps or milestones to meet in order to achieve the goals of the vision.  Effective leadership provides the focus for the teams to meet those goals by eliminating distractions and keeping the team moving forward.

Stay out of the weeds
The higher up the on the totem pole the leader is the more they should trust in the people beneath them to execute.  However, first line manager's also need to trust in the individual contributors that make up the team.  The goal should be to empower the team to effectively tackle whatever problems they are facing.

Balance the needs of customers with the needs of employees
These 2 groups are the most important for any leader to focus on.  However, often one side or the other can be neglected.  The goal is to provide customers with a compelling product or service and at the same time entrust the employees to build it.  When problems arise, it is important to balance the impact to these 2 groups.  Without customers you don't have a business and the same goes with employees.  If both groups are happy, life is much easier.

Recognize that change may be needed
In the book "The Lean Startup" by Eric Ries, he talks about the goal being to find engines of growth.  This is ultimately the goal of the company as it is responsible for driving revenue.  However, overtime the market changes and what once was driving growth may not longer be effective.  This is extremely important in the technology sector which seems to be changing all of the time.  These changes often must be adapted to.  It is an effective leader that can predict when to change and when to stay the course.

Keep finger on the pulse
Understanding the environment, whether customers, employees, or the market.  Often the information on when change or decisions are needed is available before the decision is critical.  By keeping your finger on the pulse and listening to feedback openly you will be able to head off problems before they become too disrupting.

Support the Team
You are the team's champion and there is a good chance that you will need to fight for them.  A leader represents the team and needs to be able to support them effectively.  Listening to the team and understanding their needs is a critical role.  Removing obstacles is an important part of the job for leaders.  Leaders are there to serve those under them while providing value to those above them.  Often these 2 roles can seem to be at odds with each other, but the reality if the team is executing on the things it needs to execute on, value will be provided up hill.

Assess One's Self
No one is perfect, at least I haven't met anyone that is.  It is important to constantly measure yourself and get feedback in order to improve.  This is often one of the most difficult parts of leadership.  Addressing your weaknesses is difficult, but without recognizing your short comings you cannot improve.  Leadership is a skill and needs to be honed through practice and effort.

The importance of addressing technical debt

Fixing Technical Debt has been a passion of mine for a very long time.  It is often the most impactful endeavor that software developers can do to affect the business in a positive manner.  But before we can correct technical debt, it is important to understand what "debt" is from a technical software perspective.

Ward Cunningham coined the debt metaphor a long time ago to explain the costs associated with software development and speeding the process up.  He compares it to borrowing money from a bank and how that allows you to do something beyond your current finances, such as buying a house.  The catch is that you have to pay back the loan plus interest.  You can see a video and transcript of Ward explaining the metaphor here.

http://agile.dzone.com/articles/understand-high-cost-technical

Like most things in the software business, a balance is required.  Balance between "borrowing" in order to increase feature availability and re-paying the debt incurred as we increase our knowledge and experience.

Over the course of my career, I have worked at all sorts of companies from the start-up with 6 people to the largest multi-national corporations.  What is interesting, is the lack of balance can be found at companies of all sizes.

What I have found is that the startup mentality is often to assume more debt in the hopes of becoming profitable through the acquisition of customers.  This is done by creating a product and adding features that are valuable to a customer base.  However, as the company and product matures, you reach a point where the income-to-debt ratio begins to take its toll.  Meaning that you reach a point where the company must start paying back on its debt or you will see a diminishing rate of return on the work you can complete.

This transition is often one of the hardest for a company make and the earlier that a product can make the change, the better off the company will continue to drive an engine of growth.  In fact, the technical debt metaphor explains that if the cost of the interest on the debt increases to an amount that is greater than revenue, the entire growth engine to stalls. This is obviously a disaster scenario for any company.

So how do we address technical debt?  This is not an easy question to answer, as each case can vary greatly.  However, there are some simple steps that can help drive the decisions to make the journey a successful one.

1. Consistent Vision

This is one of the single more important aspects of building a product.  You MUST know what the long term vision of the product/business is.  This is a 50,000ft view of things and I like to think of it as a compass point that point that direction that we need to head.  Everything that we do should be measured against this vision/direction.  One of the major generators of technical debt, especially in the early stages of a products lifecycle, is not understanding the needs of customers and frequent changes in direction.  By the time you are ready to address your technical debt, you should have a good foundation on what problems your product solves and how it solves them.  This should set the Vision.

A consistent vision is important for understanding and building new feature functionality as well as addressing technical debt.  More often than not, I have seen, the greedy shortsightedness of the business try to build a feature that is counter to the vision of the product because they are chasing a specific customer.  If you continually chasing business or attempting to be everything to everyone you will quickly find yourself under a mountain of technical debt.

2. Identify Milestones

Milestones provide 2 different pieces of information to the company that is trying to solve technical debt.  First, milestones help define problem areas within the business and secondly, they provide for a goal and timeline that aligns with the vision.  Milestones are the main driver of work and will detail the process and the acceptance criteria.

3. Disciplined Execution

The last item to address your technical debt is Disciplined Execution.  This is where the rubber meets the road, however it is important that the execution is well thought out and meets the milestone that it falls under otherwise you could be setting yourself up for adding debt instead of paying it off.  Disciplined execution means building off of simple concepts to grow a products functionality.  Do not attempt to predict how things will change or what will be needed in the future, instead build as simply as possible to meet the objectives of the Milestone.

Following this simple approach to tackling your technical debt can pay huge dividends to the products that you build and also to meeting and exceeding customer expectations.  Assuming debt is often a necessary part of building software, but that also means that paying off that debt is also necessary.  Without a plan to address debt, it will continue to grow with defaulting being the final outcome.  Good luck!  I would love to hear your thoughts & feelings on technical debt.

Waterfall Leadership in the Age of Agile

The agile movement has been sweeping the software development world for years and it is clear why. The agile method is a more natural way to develop software and produces results.  These results are also delivered sooner and with better visibility than the older more traditional methodologies, like waterfall SDLC. However, agile is not perfect and everyone's implementation seems to be different.  While this is normal and even encouraged, it leads to the question 'why?'.

One major difference that leads to an inconsistent implementation of agile (specifically Scrum) is the makeup of the leadership team.  In Scrum, there is one tenant that is stressed more than any other: The Team.  Everything is designed around making the team as efficient as possible.  Decisions are made at the team level, empowerment of the team to make decisions, communication within the team is paramount, succeed/fail as a team, etc. However, when the leadership or business is not also aligned to the Scrum methodology problems occur.

The development team is meant to be self sufficient.  In order to achieve this, roles must come together: development, QA (Manual/Automation), UI/UX, Business (PO/BA), DevOps, etc.  The team can achieve whatever is asked of it because they have the right skills and experience across all of the disciplines.  However, often the leadership is not aligned with this and each role within the team has a different manager chain that they report up through.  So while we ask our teams to work as a single unit, the management of the individuals make that increasingly difficult by not having a unified voice.

Compounding this is the fact that the business is often stuck in the waterfall way of thinking.  They are planning functional releases and working with sales to get that new functionality to the end users.  They are working with focus groups and trying to build a thorough road map and longer term plan based on what they learn.  But a detailed long term plan is barely worth the paper it is printed on.  The reality is that the software world is often too fluid to formulate a detailed plan that covers anything greater than a few months that remains accurate and on point.  Don't confuse the plan with vision, which is necessary for all parties to stay on task.  From my experience, most business partners have failed to make the switch to the agile movement and breaking away from the outdated waterfall school of thought.  This is often the cause of friction and confusion between the agile and non-agile groups and usually ends with the feeling of teams of operating in "agile within waterfall".

So how do you overcome this scenario?  Well, like agile there is no hard and fast solutions.  You need to ask yourself if you are truly committed to being an Agile organization.  If you are, then there are several changes that can be made.


Single functional leadership (close to the team)

A single functional leader that spans the different roles within an organization but owns the product or functional area is necessary to ensure a consistent and single voice.  You may still have resource managers for the different roles within the team, but the work the team is responsible for requires that everyone is one the same page and is not getting mixed signals from their management streams.  There are no "side project" or my manager is asking me to do something for him, etc.  It is controlled environment where there is a single focus, the Team.  

  

Set priorities, measure, and re-evaluate

One of the major concepts behind agile is to work on smaller unit and to deliver benefit earlier.  This often means that functionality is delivered and then refined over time.  This is especially true in SAAS products.  The business needs to set the course and provide information as needed.  When the solution is delivered, we need to measure to see if the changes are achieving the goals.  If we get positive results than the process should be to iterate and increment.  This constant cycle ensure we are moving toward the long term goals.  

Sell what you have, not what is coming

This idea seems to be very difficult for people to implement as it is human nature to talk about the exciting upcoming features.  The problem is the agile way is to deliver incremental functionality and to re-evaluate based on measurement.  Unfortunately, that means that what is important today may not be that important tomorrow.  So if you are selling based on a promise that we will deliver some functionality in a certain amount of time you are setting yourself and your customers for disappointment.  The customers will almost definitely see this as over-promising and under-delivering. 

Deliver smaller and iterate

The agile team itself needs to deliver smaller units of work.  The idea is that by doing this all time time, it becomes easier to measure and re-evaluate.  The process of shipping a new or modified piece of functionality becomes easier due to the frequency and practice.  The functionality can be refined over time and the product can grow based on the priorities of today, not the priorities that were based on assumptions from the past.

The Agile methodology is not limited to the functional teams that make up the organization.  To fully see the benefit of the Agile methodology all parts of the company need to embrace it.  Working within a waterfall environment while conducting the agile ceremonies will not provide the value that these methodologies can.

      

The Technical Bully Interview

Recently, I have been involved in a lot interviews, both from a hiring manager point of view and consulting with friends and colleagues that are looking for new opportunities.  I am always amazed at how different people conduct interviews.  Some are enlightening, others lackadaisical. Most recently, I have been witnessed a surge in what I refer to as a "technical bully".  These are individuals who fit a certain stereotype of software developer.  Unfortunately, the stereotype it is not  the Hollywood version of a lovable nerd with a big heart.  No, these folks often lack the people skills to effectively communicate and are out to prove something, usually that they are superior in technical knowledge and experience than the candidate.  While this must do something to stroke the bully's ego, I find it counter-productive to the goal of hiring quality people.  What is worse, is that these technical bully's are usually quite talented and experienced and so are often included in the interview process. 

Here are some common things technical bullies do in interviews:

1.  Act annoyed by having to do the interview.  

You only have a moment to make a first impression and if you come across as being put out and annoyed at having to do the interview you are already sending the wrong message.  Speaking of being put out.  Chances are the candidate had to take time off from his current job, get dressed up, drive to the office, get there early, etc.   Lets be honest, interviews are a pain in the ass for everyone involved.

2.  Continue to ask questions until you either don't know the answer or get it wrong.  

I am not sure if this is trying to measure where your knowledge/experience ends or if it is to guage how you measure up to them.  Either way, it generally isn't productive after you have shown competency in a subject area.  I have witnessed bullies asking dozens of questions in a specific area that is only tangentially related to the role being applied for.    

3.  Continue to ask questions in areas that you express that you don't know or don't have experience in.

Much like the second bullet point, it is impossible for people to know everything.  So when a person clearly doesn't have the knowledge of a particular topic continuing to drill the person on it is often counterproductive and can cause the candidate to become defensive.  

4.  Expect you to be able to read their mind, follow their train of thought, or understand the pain points that need to be dealt with.   Especially when poorly communicated or not communicated at all.  

Technical bullies often have their blinders on.  They are concerned with their problems and don't have the time or desire to put that aside to focus on the role's need and bigger picture.  Combine this with an inability to communicate well and you have a recipe for disaster.  I have seen bully interviewers ask questions that were so vague the candidates almost didn't know they were asked a question.  If you can't ask a question and communicate effectively, how are you going to be able to setup the employee for success if they do take the job.      

5.  Not smile.  

This might seem obvious, but smiling is the single most important thing you can do.  We spend a lot of our lives at work and most people would prefer to make that time as enjoyable as possible.  This is in direct conflict with the bully interviewer's primary agenda of intimidating the candidate.  

I try to follow a different approach to hiring talent to join my teams.  For me, the team is paramount.  The team being greater than the sum of its parts.  A high performing team not only gets the work done in a timely manner, they do it at a cost (both human and capital) that is cheaper than the same number of individuals and in a predictable/forecast-able way.  This does not mean that individuals need not be skilled or experienced, but instead that the individual needs to be able to do the job while working as a member of the greater whole.  

By putting a technical bully into the interview process, you have the potential to scare away the candidates that are fundamental to team building.  Those members that are more than code monkey's that can communicate effectively, develop software, and work well with others, they are the foundation of which team can be built around.  Interviewing is a 2-way process.  It is the brief time where you try to determine if the candidate can do the job and will not be toxic to the team.  But it is also the time where the candidate is trying to determine if the company, culture, and team will be a place she wants to be.  At face value, it makes sense to put the technical expert into the interview room to determine if the person has the chops to get the job done. However, you may want to take a moment to determine if that person is a technical bully and if the reward is worth the risks.  

Primary Roles vs Supporting Roles in Software Development Companies

There are 2 primary roles within any software development organization:  Engineering and Sales.
All other roles are secondary, but play a role in supporting one or both of the primary roles.  Secondary Roles include: product management, project management, program management, user experience, quality assurance, marketing, business analysis, technical writing, customer support, etc.

In a way this has a lot of parallel's to the concept of Pigs and Chickens in Agile Methodologies. Engineering and Sales are representative of the Pigs.  They have skin in the game and are responsible for creating the product and getting people to buy it.  The secondary roles, or Chickens, are supportive roles to help make the primary roles successful.

Surprisingly, it is not uncommon for the organization to get this wrong, which can have catastrophic consequences.  From a development point of view, the most common mistake is making engineering a secondary role.  Most often switching places with Product Management.

Engineering software solutions is half art and half discipline.  Because of this, driving solution design without input from the engineers themselves will almost always lead to a less than ideal technical solution.  Unfortunately, everyone likes to be part of determining the solution.  This is not a problem as long as people understand that there are always trade-offs that need to be made.  If time of delivery and cost are not an issue (and they always are), then we can all work together to design the perfect solution.  Too often time & money is spent in gold-plating a solution instead of building a product that delivers value to the customer.  This could be as simple as adding features or functionality that is easy to market or demo's well, but doesn't really solve a problem.  These features can be expensive to build and maintain and ultimately lead to a poor customer experience because they don't return on the marketing or sales promise.

What kind of "shop" are you?

The Sales Shop
Sell, Sell, Sell is the mantra of this type of organization.  The sole focus is on obtaining the customer at any cost and this almost always means feature development.  The Sales Shop is often a necessity for start-ups, but mature companies often get stuck in this mindset.

The Marketing Shop
This type of organization has completely lost sight of reality.  Their entire world is marketing spin and they not only produce it hoping to aid sales, but they also consume it.  The goal is not to produce a quality product, but to look good to the marketing analysts.  Smoke and mirrors are the tools of the trade of this group and a good "rating" is more important than actually satisfying the need or solving an actual problem.

The Product Shop
Product shops are focused on creating the best possible product irregardless of whether there is a market for the product.  This type of shop works under the assumption: if we build it, they will come.  This shop often gets caught in a the vicious cycle or work and rework.  Timelines can be drawn out as the solution is constantly evaluating if what they have could be better.

The Development Shop
Development shops like technology for technologies sake.  The focus is on the technology itself and can often lead to a lack of focus because of the constantly shifting and changing technology landscape.  The development shop often chases the change in search of the latest and greatest technology.

Why Java Code's 'Instanceof' and 'Reflection' have a "smell"

In my 16 years of writing code, I was privileged to work under some very talented developers.  These mentors were often some of the harshest critics of the code I was writing and I feel that they helped sculpt my code style over the years.  They all had different styles, some took me "under their wings", others took a more direct approach, still others were more like the Drill Sargent that is portrayed in the movies when the youth join the military and are shipped out to boot camp.

One of the staples of the lessons I learned over the years is to recognize what I refer to as "code smells".  Code smells are pieces of code that are either poorly written, don't solve the solution in an ideal manner, or fail on some level.  Usually, the code smell has to do with someone missing one of the basics of writing good code.

Most of my experience has been writing code in the Java language.  Java is a powerful object oriented programming language with a very diverse tool-set and ecosystem of third-party libraries.  One thing that Java doesn't do is protect you from yourself.  This means that just because the language supports something, doesn't mean you should be using it.

In my time writing code, there are 2 mistakes that I have seen over and over again.  These 2 smells often point to a larger problem within the code base itself.  They are the use of:

instanceof - In java the instanceof keyword can be used to test if an object of a specified type.  This seems harmless at first glance, but it is a code smell because it points to a bigger problem with the code you are writing.  Use of instanceof points to a failure of proper polymorphism, a pillar of object oriented programming.  Deficiencies within your object model are something that should be addressed as a top concern.  Ensuring that the logic you write meets the basics will lead to a better solution over the long term.  There is one exception to the rule.  The instanceof keyword is fine to use within an "equals" method.


reflection - in java the java.lang.reflect package is a series of utility classes that allow introspection on running code.  It is an extremely powerful concept, but generally should be avoided within production code.  I often see developers using reflection as a swiss army knife within the jvm.  Not only is this bad practice, but it has a significant code smell.  Reflection breaks several of the pillars of object oriented programming.  It overrides encapsulation and it can work around both inheritance and polymorphism.

There are many other code smells and perhaps we will be able to touch on some of them in the future.  Today we covered two of the most common coding mistakes I have seen in my career, the use of the instanceof keyword and leveraging the java.lang.reflect package of utilities in production code.