Why a tool doesn’t bring you business success
A couple of days ago FC Internazionale Milano won the UEFA Champions League final. Is it due to the qualities of Wesley Sneijder? Although he’s an excellent football player it’s definitely not due to his individual qualities only that Inter won the Champions League. Is it because of the coach, Jose Mourinho? He definitely played a big role, but it’s still a combination of a team and it’s coach. Is it due to a technical head start in equipment?
Let’s stop trying to come up with more questions, I’m definitely not an expert in this field.
When I was musing about this subject I realized something. On this blog I write about technical stuff: Service-Oriented Business Applications, Model-Driven Software Development, and a combination of these subjects in something like Model-Driven SOA. I like to think and write about these subjects, I also like to explain why these techniques can give you real business advantage. However, in practice, it’s not the tool which brings you business success; it’s a combination of a team and a tool.
Empowering a team with a tool
A fool with a tool,
is still a fool
bringing disaster faster.
A tool always contains a balance between flexibility and guidance. The more flexibility, the more a team needs to decide on its own how to use the tool. For example, when using a Model Driven Development tool the team has to decide what models have to be created in what order. Other decisions include change management, work breakdown, project management, etc. That’s why tool needs to be accompanied with a methodology. Or, better: a tool implements (or supports) a certain methodology.
It is people who develop software. Their productivity can be improved a lot using tools, however, they’ll need guidance on how to use these tools. Templates can help to make the start with a tool a lot easier. Reference models can help to show the best practices. Both can provide guidance and structure. This is one of the reasons we recently introduced the Mendix App Store, tightly integrated with our Model-Driven Development environment, to search and download templates and model parts directly into our tool.
Again, it is people who develop software, so even methods and tools are not enough. Ivar Jacobson, one of the founders of the SEMAT initiative recently wrote about two complementary macro-trends in software engineering. He states that besides methods and tools (e.g. the SEMAT initiative), we also need professionalism and craftsmanship. There’s a human side to software engineering and what we need to improve this field is better training and education for people to become professional craftsmen.
I believe we need tools to make teams more productive. However, tools are not enough. We need to empower teams with a tool by providing accompanying methodologies, templates, references, and by not forgetting the human side. After all, it is people who develop software.
The importance of a team in building a tool
It’s not only the team using the tool playing an important role. The single most important thing I learned in the last couple of years is that to build a successful software product you do not need a team of excellent people, you need an excellent team of people. The latter doesn’t exclude the premier of course.
In this piece explaining the dangers of programming alone, there’s an excellent quote (source doesn’t exist anymore). I couldn’t express my feelings around the importance of a team in a better way, so here it is:
Some folks have claimed that [working alone] presents a great opportunity to establish your own process. In my experience, there is no process in a team of one. There’s nothing in place to hold off the torrents of work that come your way. There’s no one to correct you when the urge to gold-plate the code comes along. There’s no one to review your code. There’s no one to ensure that your code is checked in on time, labeled properly, unit tested regularly. There’s no one to ensure that you’re following a coding standard. There’s no one to monitor your timeliness on defect correction. There’s no one to verify that you’re not just marking defects as "not reproducible" when, in fact, they are. There’s no one to double-check your estimates, and call you on it when you’re just yanking something out of your ass.
There’s no one to pick up the slack when you’re sick, or away on a business trip. There’s no one to help out when you’re overworked, sidetracked with phone calls, pointless meetings, and menial tasks that someone springs on you at the last minute and absolutely must be done right now. There’s no one to bounce ideas off of, no one to help you figure your way out of a bind, no one to collaborate with on designs, architectures or technologies. You’re working in a vacuum. And in a vacuum, no one can hear you scream.
If anyone’s reading this, let this be a lesson to you. Think hard before you accept a job as the sole developer at a company. It’s a whole new kind of hell. If given the chance, take the job working with other developers, where you can at least work with others who can mentor you and help you develop your skill set, and keep you abreast of current technology.
In short, you need an excellent team of people to:
- structure the development process,
- brainstorm, crunch knowledge,
- collaborate on ideas, designs, architectures,
- to keep asking for the rationale behind incoming requests,
- strive for excellence.
But also to:
- prevent you from pitfalls,
- review your work,
- keep you on track.
I can tell you that being part of such a team is not only a beautiful experience, it also leads to exciting results!
Creating the right environment
No matter in what place of the chain of software development you are, you will need an excellent team of people to really succeed. For example, as mentioned before, a team building a tool, or a team using a tool to build a business solution. The question is: how to ‘create’ such a team. Or, formulated in better way: how to create an environment in which such teams prosper?
A lot has been written about this subject. Freedom and empowerment are important key aspects in building excellent teams. As a starter into this subject I recommend to read Twelve Tips for Team Building: How to Build Successful Work Teams. Another interesting article in this area is Urs Peter’s summary of a seminar by Marc Lammers, one of the most successful hockey coaches ever. He shares the principles Marc Lammers discovered and describes how they can be applied in software development.
Another important aspect in creating the right environment is to motivate people. When motivated a team can face almost every challenge, if not there’s nothing you can do unless you find a way to motivate your team. You really should watch this excellent, cartoonish movie explaining the truth about what motivates us!
In short: once the tasks people should execute call for rudimentary cognitive skills, a financial reward doesn’t work, it sometimes even lead to less motivation. There are 3 factors that motivate people:
- Autonomy: the desire to be self directed.
- Mastery: the urge to get better at stuff.
- Purpose: the need to make a contribution.
For a list of practical points see 25 sure-fire ways to motivate your team members.
While context and people are always different, there’s no straightforward guide telling you in detail how to build an excellent team. In my experience the first step (of a manager) in creating an excellent team is taking a step back.
What are your experiences in successfully adopting a tool? What are the key success factors in your opinion? What should a tool provider do to make sure a team can get the most out of a tool?