There are many different types of leadership style you can adopt and rarely does one size fit all. Sometimes over the lifetime of a team you will need to adapt your style to fit a certain scenario, or use a specific style with different people on the team, especially if they are persistent under-performers.
You need to adapt your leadership style to different scenarios.
Bureaucratic Leadership
Bureaucratic leaders are people that follow rules to the letter, and they ensure their team follow rules and process to the letter of the law. If you are working in an environment where safety both to people and systems is essential then this type of leadership style is needed. If you have a team that does a lot of repetitive and manual work, then this style is also very well suited. If you want your people to be creative and innovative, then this isn’t the best style. You can use a blend though where you slip into bureaucratic leadership if you have a strict deployment or change management process to follow.
Since I wrote my article recently about Google’s 9 principles of innovation a reader over on Reddit pointed me to a resource on some more good design principles. These are the 10 Principles for Good Design by a German industrial designer Dieter Rams.
Dieter Rams : 10 Principles of Good Product Design
Dieter Rams introduced the idea of sustainable development and of obsolescence being a crime in design in the 1970s. Accordingly he asked himself the question: is my design good design? The answer formed his now celebrated ten principles.
Whilst Dieter was an industrial and product designer, his principles can fit anywhere where good design comes into play. In the rest of this article, I will explain what the 10 principles are, and how I think they fit into software development.
The principles in this article are very useful for software developers and designers, but this is also very relevant for technical leaders. As a leader it is good to try and push your teams to make sure they are thinking about the end user. Traditionally, software developers make lousy designers (not all of them before I start a flame war), but aesthetic design, generally, isn’t something that comes naturally to programmers. Therefore having principles like these is great for giving you pause to reflect on how your system / application affects your end users.
The different product images below are examples of products designed by Dieter. Those of you old enough may recognize a few!!
Whilst doing my daily trawl through the internet and Reddit pages, I came across a very interesting talk at the San Francisco Dreamforce Summit where Google’s Chief social evangelist, Gopi Kallayil talks about Googles 9 principles of innovation. Please do go and watch the video as it is a great insight to the inner workings of Google, but here are the 9 principles summarized here.
Googles 9 Principles of Innovation
Innovation comes from anywhere
An idea for an innovation doesn’t have to just come from your super star employees. Ideas can come from anyone. There is a really good example that Kallayil mentions where an onsite doctor at Google had idea that if someone talks about suicide in a Google search that the first item in the search results should be the phone number for the National Suicide Prevention Hotline. The call volume to the helpline went up 9% after that. This is a great example that an idea for an innovation, no matter how small, can have a big impact.
Google’s automatic reference to a suicide hotline.
Due to the impact of this one small change, they have now rolled this type of change out across the world. In the screenshot above you can see where it shows the phone number of the Samaritans.
In this 3rd part of the series I want to talk about innovation and how you can encourage it within your teams. Being able to innovate is something every developer should want to do, but you need to control the innovation process properly otherwise you can end up with a team just doing their own thing and taking their eye of the ball for the business.
Encourage your team to innovate solutions.
What is Innovation
“Innovationis the application of better solutions that meet new requirements, in-articulated needs, or existing market needs. This is accomplished through more effective products, processes, services, technologies, or ideas that are readily available to markets, governments and society. The term innovation can be defined as something original and, as consequence, new that “breaks in to” the market or into society. One usually associates to new phenomena that are important in some way. A definition of the term, in line with these aspects, would be the following: “An innovation is something original, new, and important – in whatever field – that breaks in to (or obtains a foothold in) a market or society.”
As the quote above says, innovation is the application of better solutions that meet new requirements. I believe it is important to try and foster a culture of innovation in a software development team as your developers (I am including QA’s, UI designers, and anyone technical in this too) are the brains behind your companies systems. Innovation can come in many forms. It could be an idea for a completely new system, or it could be an enhancement to an existing system or process. If your innovation could end up taking a large amount of time to implement, maybe you can do a proof of concept first to sell the idea to your management or business sponsors.
I want to give an example of a recent innovation that has come from my team and talk about how it has benefited the business. This is an example that ended up being a large revenue generator, even though the actual ideal was quite simple and didn’t take that long to implement.
In Edmond’s his article he proposes 5 strategies for finding meaning in your work. I want to list them here with my own thoughts, but please check out his article to get his own thoughts on them.
Validate new ideas early and often with simple proofs of concept
This strategy really speaks for itself. Before investing a large amount of effort into something that may not work out, you should try out a proof of concept first. Generally a proof of concept will be a throw away piece of code just to prove whether a theory will work or not. When my team write proof of concepts, they don’t even bother writing unit tests for them, as the code is never destined to be production code. You can even take this POC idea further by following some of the Lean Startup ideas and produce a larger working mock-up of a system, or a minimum viable product as described in the book.
The Lean Startup – Eric Ries
We tried this in my team. We had a project that our debt recovery department wanted to initiate, which is a self-service portal on the web to allow customers who are already in debt to make a payment online, and therefore avoiding a difficult conversation with our debt collectors over the phone. The idea made a lot of sense, but before investing a large amount of money in building the portal, we did a lean start-up style set of experiments to test the theory against a minimum viable product.
In this series of articles I want to discuss some topics for software development leaders around motivation, innovation, and the different leadership styles you can use to support your team. When you are leading a team of software developers, or indeed any knowledge workers, you need to keep them motivated to continue getting the best out of them. There are many ways to do this, and they don’t always involve paying people more money. In the rest of these articles I am going to discuss some thoughts on motivating developers.
It is a really good article and I want to pick up on a few points and discuss them further. There are many different ways to get someone motivated, but by far the biggest for a knowledge worker is to give them meaningful and challenging work.
A little while ago I wrote an article about training for software developers. This article focused mainly on developers increasing their technical knowledge. In this article I want to expand on that and talk about a developer’s skills matrix that we use in my department. The skills matrix discussed here was originally put in place by our old development manager, Duncan, with input initially by me and the other leads at the time. Once we had the base matrix in place we gave the developers an opportunity to contribute to it.
Training for Software Developers : Knowledge, Skills, Behavior
In our company we have 3 levels of developer under the team leaders. They are Entry Level Developers, Developers and Senior Developers. The skills matrix is split into 3 sections, Knowledge, Skill and Behavior.
Knowledge is the information we expect developers at each level to know as a minimum.
Skills are what we expect a developer to be able to do, i.e. the doing.
Behavior represents the habits of a developer.
Let’s use an example of source control. For knowledge we would expect someone to have a good understanding of source control concepts. Why do we use source control? What types of source control system are out there? What is branching and merging etc? For Skills we expect someone to be able to use their tools. In our case this is Microsoft’s Team Foundation Server. Can they check in code? Can they merge conflicts? Can they go back to previous revisions? Can they create branches? Behavior is more about their day to day usage. Do they regularly check in code as a habit? Do they keep an eye on builds? Do they fix broken builds? Are they branching on release?
