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.