I’ve been in and out of leadership roles from High School onward. For the past decade and a half, I’ve been a professional software developer. During that time, I’ve been in a leadership position roughly a third of the time. Recently, I was asked to evaluate my Leadership Philosophy (more on that later). I’ve also had to do the annual counselling that My company formalizes.

One tool we learned in the Army was the list of Leadership principals. As part of my evaluation, I want to see how I think they apply to what I do: Software Development in an Open Source project space. Here’s what I’ve come up with so far:

Principle #1 – Know Yourself and Seek Self Improvement
Principle #2 – Be Technically Proficient

At first blush, these may seem to be the same thing. However, this is leadership focused, and the two points emphasize different aspects of competency. It is impossible to lead in software development without knowing what you are doing technically. But Principle 1 is referring to leadership skills in particular, as well as any aspect of your life outside of coding that can impact your job. Punctuality, cleanliness, clarity of communication, focus, temper, and so forth. You might be the smartest code jockey in history, but it doesn’t mean you have all the necessary skills to lead a team.

That said, you should be able to do the job of everyone under you in your team should the need arise. Probably the most important reason for this is so that you can ensure that what each team member is doing contributes to the overall success of the team. If you cannot read SQL, you won’t be able to understand what your DBA is proposing. Code is code, and you should be comfortable with all programming languages and paradigms. What, you are not? Get studying.

Principle #3 – Seek Responsibility and Take Responsibility for Your Actions
Principle #4 – Make Sound and Timely Decisions

Sometimes a technical lead or managerial position gets thrown in your lap, but that usually happens after you have shown that you can do the job. That comes from solving problems.

Now, “Take Responsibility for Your Actions” might sound like advice to be willing to admit when you are wrong. That is only a small part of it. In reality, development is filled with thousands of tiny decisions, and not all of them are going to be optimal. Yes, sometimes you will make big mistakes, or will have to take the hit for a mistake someone on your team made despite your best efforts. That is the lesser part of taking responsibility.

The greater part is understanding that your job is to get high quality software out to your customers. You need to ensure that all of the links in that chain are covered. You might have the greatest solution to a technical problem, but if the user can’t install it, or if upgrading from a previous version will ruin the uptime of a critical system, you have more work to do. Quality Assurance takes a lot of resources, but it is essential to building quality code. You need to make the decisions that will affect not just the current code base, but the ongoing process of improving code. It is easier to make corrections closer to the decisions than down the road: make decisions, look at the impact they are having, and make continual adjustments.

Probably most important is code reviewing. Fortunately, the programming world has caught on to the fact that code reviews are good. The projects I’ve worked on these past few years have all had mandatory code review policies. However, as a senior person, your responsibility to code review is greater than ever, as you will set the tone for the people on your team.If you do cursory reviews, others will either do cursory review, or will shame you. Neither is good for your team.

You are also responsible for making sure that the code reviews are checking for certain standards. PEP8 under python, Java coding conventions, and so forth are necessary but not sufficient. This is another case where technical proficiency comes in. You need to know the requirements of your code base. For example, if you are using a single threaded dispatcher like Eventlet, make sure that none of the code you introduce blocks, or you will deadlock you application.

Principle #5 – Set the Example

Lead by example can only occur if you have the skills to do something well yourself. Often, in a review, you need to provide an example to a developer how you think they should redo a piece of code. But it also refers to that limitless list from “Know yourself.” If you show up at Noon, your developers will show up at noon. If your reviews are lackadaisical, theirs will be as well. If you are rude to members of your team, they will pick up on it, and the cohesion of the unit will suffer. If you communicate poorly, the team will communicate poorly.

Of course, this being the Open Source world, it doesn’t always happen like that. Often, someone else will step up and fill the vacuum. One member of your team that believes in good communication may take it upon themselves to be the “information pump” of the group. Well mannered project members may be better able to soothe over ruffled feathers. But often we also see communities fall apart due to rudeness and poor software development practices. Best not leave it to chance.