Software Development Leadership

Leading software development teams present many different challenges. Over the years I have come to realize that there is a core set of principles related to successfully leading software developers, principles that I will share in this post. Many of these principles are not specifically related to managing a team of software developers, but are more about leadership in general. I encourage you to develop your own set of core principles, because to be truly guided by them you must own them. I have found that innovation flows from creating a positive software development environment, and so this article is ultimately about creating the type of environment where innovation, results and team development flourish.

Core Principles

  1. Optimism
  2. Enthusiasm
  3. Integrity
  4. Perseverance
  5. Organization
  6. Empowering
  7. Collaborative
  8. Communicative


Communicate clearly and directly; do not wait to correct undesirable habits, address these habits as soon as they are observed. Praise developers when they exhibit desirable habits, never focus only on the negative. If a developer has only bad habits, this needs to be addressed right away and if not rectified the developer may have to be dropped from the team.


Be open, honest and transparent with your team and never deceive them. Take responsibility for your mistakes and learn from them, always demand the same of your team. Be honest and transparent with other groups you interact with as well. Remember that you often represent your team to other groups, and it is important that you represent the team well. Be transparent in all your dealings; always put the team above yourself. On a rare occasion, you may be faced with a situation where putting your team first conflicts with company plans. The team is depending on you to represent their best interests, so you must be willing to fight for them. However, never compromise your integrity. Check your gut and let your core principles guide you, if fighting for your team does the larger business serious harm, then direct your efforts more towards the proper treatment of your team. For example if the team is dependent on a certain product line that is slipping, and the company decides it can no longer afford to support the product, fight for the product and try to find ways to make it more profitable. However, if you realize that the company is correct to abandon the product, focus efforts on trying to find other products or groups within the company that your developers can move toward.


Always maintain a positive attitude, even when faced with crisis and difficulties. Your team will take their cues from you, if you are negative this attitude will certainly spread and infect others. A challenge is an opportunity to succeed, this is how you should look at every difficulty that arises.

Guide, Mentor, Motivate and Develop team

Talk to developers about their goals, both long and short term goals. As a leader do all you can to help then realize their goals, even if their goal is to one day have your job. Build their personal career goals into your plans for that developer, and do what you can to help them progress towards these goals. If the developer has unrealistic goals, let them know. This of course can be very difficult, but it needs to be addressed. A developer with unrealistic goals will not be happy working on the team. But be fair, an unrealistic goal is not a goal that is too high to achieve, it is a goal that you believe could be harmful to your team or the company, and therefore you absolutely cannot support their goals. Identify future leaders and delegate more responsibility to them.

Clearly communicate expectations

Let folks know what is expected of them. Low performers on the team may not be clear on the team’s expectations. Often these individuals can improve by clearly communicating expectations, and giving prompt feedback when they are not performing to expectations. To develop a high performance team, it is important to address and improve low performers. It can be demotivating for the team to see others on the team that are not making a positive, constructive contribution.

Marketing your team

Make the rock stars on your team visible to the rest of the organization.  Put the team before yourself. When mistakes are made that affect other teams, take responsibility and communicate it as a team problem that you will remedy. When dealing with the issues within the team you can address individuals responsible for the mistake, however make every effort to avoid throwing the individual under the bus publicly.

Building Relationships

Work hard, but reserve some time for fun. It is important to keep a sense of humor, and talk about common interests unrelated to work. This helps you develop a rapport with those that you lead. Empower developers and give them a chance to design and be creative in their work. Often leaders that are particularly bright and talented coders want to micro-manage design and code. Resist this urge and let the developers be as creative as possible. If you think there are issues with a proposed design or coding approach, by asking questions you can often lead develops towards a better approach while still giving them the freedom to think on their own. Build up your developers; do not tear them down unless you sincerely feel that it is warranted. If it is warranted, be blunt and honest, make your point clearly and without fear, but be careful not to do permanent, destructive damage. Always keep in mind that your primary objective during these times is to avoid a repeat and teach a lesson that will stick. Ultimately your objective is to help the developer improve and to reach new professional heights.


I have outlined my philosophy about leading software development teams, but I’m always seeking to learn and improve. So please comment with your thoughts and feedback!

InitHub Beta Launch

Today, Solutiosoft is pleased to announce the official launch of the InitHub beta program. InitHub is a private innovation network designed to facilitate forming key connections with the common goal of advancing an idea or initiative. Our goal with InitHub is to create a trusted, self governing community dedicated to bringing ideas to life.

Visit InitHub today to learn about limited time special offers.

Core Ideology


Our purpose is to create innovative, constructive and useful software products.

Key Stakeholders

1. Customer

We seek to build innovative, useful, high quality software solutions and provide exceptional service to our customers.

2. Employees

We seek to create a positive, creative and innovative environment for our employees. We are building a meritocracy, where we attract, hire and retain positive, constructive, energetic talent. Our focus is to train our people early and often in our core ideology and create concrete policies that continually reinforce this ideology. We will seek wherever possible to hire from within, and to develop and prepare our people for career advancement.

3. Community

We are committed to having a positive impact on the local communities we operate in. We seek to contribute to the continual improvement of the community, and support local organizations that are dedicated to providing assistance to those in need. We seek to develop company policies that encourage our employees to support local communities.


We are building a culture of service, innovation and excellence. We seek forward progress, continual improvement, creative dialog and adherence to our core ideology in every aspect of our company. We will always and everywhere seek to provide exceptional service and innovative software solutions, and build the internal and external practices and policies that reinforce this commitment to excellence.

Beyond Code

Software development processes for successful software

Successful software. Yes, it exists today. And it is not an accident. It typically occurs because software development teams think beyond the writing code. They consider the wider software release world, including:

  • Project Management
  • Release and Configuration Management
  • Quality Assurance
  • Production Release
  • Production Performance, Maintenance and Operations
  • Customer Support
  • Continuous Improvement
  • Creative work environment

When software development teams seriously consider these items when designing, developing and releasing projects, time is not wasted, other groups develop an appreciation for the development team, and iterations/releases go much more smoothly. Much of what I outline here is common sense to many, yet time after time I see development teams and individuals neglect this. Additionally, I often see development teams that have good intentions, but lack the time. Often external groups fail to see the benefit of the processes discussed below. It is my hope that this article helps development teams as well as other groups within a company recognize the benefit of these practices.

Development process

Requirements review

First step is to understand as clearly as possible what it is you need to build. The process for gathering and documenting requirements varies greatly from company to company. Whatever process your company utilizes, there is some form of communication to the development team regarding what is needed. It is critical that the development team has a clear picture of what is needed. Sometimes this will take place though several release iterations, but the point I want to stress is that when there are uncertainties, a developer needs to do the leg work necessary to resolve the uncertainties. A developer must also have an audit trail preserved as to the resolution. Verbal resolution is usually not good enough. You want proof that this was the resolution as it could be forgotten. I’ve seen this happen hours before a production release.

Design review

Once the development team has a fairly clear understanding of what is expected, the task of designing the implementation begins. Again, this varies company to company, from detailed design specifications to informally explaining the planned coding approach to a lead developer. This is an important part of software development as often problems can be surfaced at this point, which is still early in the process. This saves critical time and money later in the process. Don’t waste the time of other functional groups by releasing substandard code. It is preferable that the individual(s) that review the design have system wide knowledge and experience.

Code review

Once the design is agreed upon, the actual coding and unit testing can begin. Once this nears completion, a code review should take place. A code review can often surface issues early in the process. Catching issues in before release to a QA team saves time and money.  It is important not to just review the code, but to look at the code in a wider context. The following areas should be covered:

  1. Content of code changes (new features, bug fixes)
  2. Review of source code
  3. Review of testing
  4. Review of any supporting documents, such as release notes and operational guides

I recommend utilizing a code review template to capture any action items from the above areas. The code review section of the document should capture all comments and suggestions from participants. This is important part of fostering an open, creative and innovative environment. Note every item needs to be addressed, however every item should be captured. The participants can must decide if the item must be included or if it can be deferred.

Documented test plan

During the design and coding phase, notes need to be kept that detail the testing of the feature(s). These notes will then be turned into a formal test plan that is submitted to QA on or before initial release to QA. This formalizes the development to QA communication, and is an important document that is often used by production support teams. In some organizations the QA group will create the formal test plans, however the development team should still create some form of development test documentation.

Automated build process

What ever build tool your team uses, the build scripts should be rock solid and easy to reproduce. Configuration data tied to local developer workstations need to be externalized. Scripts should be created to both build and package the release. The packaging of the release needs to take into account the production installation image, and should replicate this image as close as possible. Once the scripts are created, development teams should continue to seek out opportunities for improvement. Often you can build testing scripts into the build process which lead to greater and greater quality of the basic release artifacts. When you are ready to release to QA, it is important to go through the process two complete times. First, the development team should make sure all the code for the release is checked into source control. The designated developer should check out the code, build and package the release. Once this is complete the release artifacts should be closely inspected. If the developer is satisfied at this point, label the source, totally clean (delete) all project directories and files (make a back up first). Now you are ready to go through the process the second time, only this time you check out the source from the label you created the first time. Make sense? This ensures that no artifacts on the developers machine were not in the source control tool, and it also guarantees that the release can be recreated.

Source code management

Of course source control should be utilized to support new releases and recreate existing releases. I personally use a branch by task strategy. This is where every feature/task has its own branch created. When release time comes, tasks for the release are selected and merged into an intermediate integration branch. If the integration branch passes development testing, the integration branch is merged back into the main code line and the release is cut.

Release management

By having your build process replicate the production install image as closely as possible, you make the hand off to Release/Configuration Management much easier. By thinking of the production image of your software, you anticipate and account for the process that will lead to a successful and pain free production installation. If questions come up when you are considering this, talk to Release Management, they will certainly appreciate it and will usually be more then happy to help work out these issues.

Quality Assurance

Your development processes need to be solid enough to avoid unnecessary QA cycles. When a release is in QA, make yourself available to the QA staff to help clarify any questions. This will eliminate bugs being logged that are really only questions, and it will help isolate points of confusion to person to person communication. This is usually better then exposing the confusion to a wider group, which can make the development team look as though they have not thought everything out, which in turn leads to lower confidence in the development team by external groups. This also helps you to improve your process so as to avoid the same confusion in the future.

Project management

This is the area where software development team often have the biggest challenge. I have seen development teams present realistic estimates and that are immediately rejected. Often the team is forced to revise the original estimates to meet project management time lines. I recall a manager presenting a development schedule that estimated 8 weeks of development. The response from the project manager was a “no way” and “for these requirements” and “did you really read the requirements”. Eventually the software development manager agreed to revise the estimate to 6 weeks. The scope of the release was not changed. At this point, timelines were communicated a wider audience, including the end user community. When the project actually took 8 weeks to complete, the project manager was genuinely confused why it took 2 weeks longer then the estimate, questioning the team’s ability to estimate projects. Software development estimation is critical to software success. You must provide reasonable estimates and stick to them. Do not compromise unless something of equal value, like a dropped feature or added resource, is agreed to. Otherwise you must make it clear that the quality of the release may be compromised if the schedule is indeed pulled in. My motto is “Under promise and over deliver”. In the end your team will look much better being 1 week early then 2 weeks late. At the end of the day most companies will come to realize the benefit to both internal teams and external customers of delivering on time, and an important aspect of this is properly managing expectations and estimates.

Customer Support

This part of the organization is critical. Poor customer support leaves the impression of poor software, whereas excellent customer support will give your customer confidence and leave the impression of quality software, or at least a culture of customer focused continuous improvement. The software development team can help create a first class customer support group by careful attention to the items outlined in this article. Good documentation and prompt attention when customer support requires more expert guidance also will make a huge difference, so don’t ignore this aspect of the software process.

Managing the knowledge that is created by all the processes defined above is an ongoing and critical activity. Developers need to be knowledge management experts. Wiki’s are idea for managing this information. Note that it is critical to continually update whatever knowledge repository you use. Do not let the information get stale!

Continuous Improvement

Software development teams need to continually measure the results of their processes and improve wherever they can. The processes outlined within this article are not static. They need to be adjusted for your organization, measured and improved upon. Continually. It takes a real commitment to a holistic software design and development discipline.

Creative work environment

It is important to foster a creative and innovative environment. The team should always be open and encouraging to ideas and suggestions that improve processes, policies, and software. It is often helpful to have periodic idea storm sessions were everyone is confortable making suggestions. It is often helpful to capture all suggestions, and not discuss the merits at an idea storm session. This will encourage folks to speak up without fear of having defend the idea. This can be a fine line. It is very helpful to discuss the actual idea, as others often speak up and help refine the idea, thereby making it better. However, all participants should refrain from judging any ideas.


As you can see, each aspect of the development process takes into account external functional groups. The processes defined above thus lead to quick iterations and confidence within external groups. This in the end is critical to the success of software. Quality Assurance, Release Management, Project Management, Operations, Executive Management and in the end the customer, all benefit from solid development processes. They appreciate the attention your team paid to quality, performance, release and operational issues. They are as busy as you are, so don’t waste their time!