Paul is a programmer. He has over 10 years of professional experience. During this whole time Paul has been building an impressive technical culture that covers a large number of principles, patterns, practices and technologies and it’s anything but superficial. Actually Paul has been enjoying programming as a true hobby since he was fourteen. Still, there’s something else that makes Paul a consummate professional: his attitude.

Paul has some special attitude. His experience has been inevitably growing with time but it was exactly his attitude that built the knowledge. What’s so special about this attitude? Personal commitment to excellence, pride in his work, discipline… Paul is a high KEA programmer. He’s got high Knowledge, Experience and Attitude. Paul is a true software craftsman! He really feels and embraces the Agile and Software Craftsmanship values. Paul knows and feels that in software the only way to go fast is to go well and that speed kills. In the most simple observation context, a small project in which Paul would be the only technical guy in the team, the quality of Paul’s work (functional and non-functional) would be very high…

 

Andrew is a programmer too. He is smart and spontaneous. Like Paul, he also spent the last 10 years of his life programming but his technical culture is quite low…That’s because Andrew doesn’t have Paul’s attitude. No work pride, no commitment to excellence, no discipline… Programming has always been just a job for him. Andrew has always been happy if he could just throw some code (anywhere) that could pass some basic functional paths that he could think of in first place and then stretch it and force it to functionally cover more paths and make QA happy. (Not to mention TDD) Non-functional requirements like performance, scalability, maintainability, extensibility and reusability have always been just academic fuss for Andrew. He was always in a hurry since development speed was the single value that he could understand and adopt. Andrew never reached that level of technical maturity to actually feel that speed kills. Andrew is obviously a low KEA programmer. In the most simple observation context, a small project in which Andrew would be the only technical guy in the team, the quality of Andrew’s work (functional and non-functional) would be very low…

Thinking about an evolution in his career, besides being so eager to constantly develop his technical skills, Paul wants to be a technical leader. He always had some people skills and very much enjoyed sharing his knowledge. He had the chance to grow a few juniors and realized that he loves to craft people same way as he crafts code.

He has some theory about the dynamic level of authority that he, as a technical leader, would apply for every member of his team:

James and Patrick would have their own KEA-Authority graphs according to their evolution but Paul’s authority would always be inversely proportional to their KEA. These graphs should be discussed and the KEA periodically re-evaluated in one-on-one discussions with every team member. Of course Paul would also be responsible for growing their KEA by whatever means: providing technical resources, doing technical presentations, pair programming…

Andrew wants a career evolution too and he’s thinking about a small-scale management position. He didn’t really think through the responsibilities he could take on but what he knows for sure is that he is already experienced enough to lead a team of developers and tell them how to write code, when to write it and especially how fast to write it. He could also take on some project management responsibilities and even merge everything with a product owner role but the idea is to stop writing code and do a more high level, more business, more strategical work that is suitable for smart people like him and that should come as a natural “upgrade” after all these years spent as a programmer. He didn’t really think about authority graphs but if you read this far you already know Andrew well enough to imagine how his authority would manifest in time:

Paul and Andrew live in the same city. Paul works for Company A and Andrew for B.

At some point, Paul gets a technical lead/architect role in a small team having all the guys sharing his attitude but various lower levels of K and E. They start working on a green field technical solution for a brand new product of his company. Paul applies his dynamic authority strategy and invests a lot of energy in knowledge sharing and technical guidance. After just a few months everything is going great: the quality (functional and non-functional) of the technical solution is sky high while the guys are a lot more knowledgeable and experienced. At this point you can barely feel Paul’s authority and they are very close to the ideal Agile self-organizing team (Principle 11). They are a team, they are craftsmen, they are friends and they are happy.

Andrew also gets a team lead role in a small team having all the guys sharing his attitude and even lower K and E levels. His role is a mix of technical leadership, people management and project management responsibilities but he doesn’t care as long as he can do what he loves most: feeling important. They also start working on a green field technical solution for a brand new product of his company. In just a few months they manage to implement some of the prioritized features but upper management starts to smell some problems. They still have a huge backlog ahead but the team is slower and slower and so is the system at runtime. The maintainability, extensibility and performance of their solution is a joke since they didn’t really apply any good patterns, principles and practices. The problems are becoming more and more acute and visible but Andrew is incapable of realizing that speed kills and instead he is presenting various naïve excuses to the David, his manager.

David meets Paul and decides to hire him to save this project. Still David thinks that Andrew is doing a good job in his role because he knows the context so well: the team, the technical solution, the product. He is seeing Paul just as a senior developer knowing the patterns, principles, practices and their technology stack of choice way better than Andrew but lacking Andrew’s great people leadership, product knowledge, company culture…David hopes that Paul can refactor the technical solution in order to speed-up development and maybe even inspire at least few of the guys in the team to develop their technical skills. But David cannot give Paul a role with technical authority since he doesn’t want to risk any conflicts with Andrew while also confusing the entire team.

Paul is in a pretty vulnerable period. He thinks he needs new challenges, new domains, new people and, why not, new money so he resigns from company A and joins B as a senior programmer in Andrew’s team. Long story short: it doesn’t work like David expected. The technical solution is too messy, Andrew’s authority is too aggressive, Andrew’s and David’s top priority is still speed, Paul is too friendly, his role has no authority while the other guys in the team are too possessed by the culture in which they grew – Andrew’s culture. In this context even the quality of Paul’s work significantly decreased compared to what he used to produce when he was alone on his small projects or together with his dream team at company A:

Paul is frustrated and quits. But soon he is happy again as he starts with company C in a role and a team that is very similar to what he had at company A.

Unfortunately, as you might expect, after a short time, Andrew’s project at company B collapses as a technical failure and Andrew is fired.

Andrew has a hard time finding a new job in a similar role so he ultimately has to “downgrade” to technical roles again. He joins company C as a senior developer in Paul’s team. After a few months Paul still needs to keep up his authority with Andrew since Andrew’s KEA didn’t improve but still, interestingly enough Andrew is producing the highest quality in his whole career while the overall team quality remains high.

Sounds like a happy team. One problem though…It is not Andrew the one who produces that quality. Andrew’s contribution to that team is just a pair of hands that are mechanically following the direction provided by Paul, the rest of the team and the actual technical solution. Andrew is waiting…waiting for a new chance to “upgrade” to an important role again so he can use his authority to build more products and more people in the way he knows best…

Why did their lives turn out this way? Why does Paul have that attitude and Andrew doesn’t? Paul has been enjoying programming as a true hobby since he was a teenager…Does that even matter? Maybe Paul was lucky enough to have an older Paul as a leader and mentor when he started his professional career while an older Andrew took care of Andrew…How Paul’s life would have been if he had started his professional career with his hobby but with a leader like Andrew? How Andrew’s life would have looked like if he had started his professional career with a leader like Paul?