The Making Of Professionals

Prologue

When I was a student, there wasn’t a week passing by without a couple of assignments. Many assignments were theoretical. I’ve never cared much for these ones. Programming assignments were my favorite. Whenever I received a programming assignment, I was excited: I was about to create some brand new world with my ten fingers (and a keyboard). This is what I liked doing best.

The best part for me in a programming assignment was thinking about the design. I loved that, and still do. For me, this is when the real creation took place – when the vision started to emerge, even if only on a small whiteboard.

Then, in my second year, I was given an assignment in what was considered the most important course of that year. It was not just a regular assignment. It was the final assignment of that course. Although I had many other assignments at that time of the year, I couldn’t resist the temptation, and I immediately began to work on my project’s design. I had a strong intuition regarding the structure of the project, so I felt pretty confident starting to implement it after only one hour of design work. Of course, half way through development I realized that my initial design was far from being optimal for the problem I had to solve, so I gave it some more thought and fixed it on the fly.

A couple of weeks later, my solution was ready. I was very proud. I really felt I had done a great job: great design, superb implementation, and even some useful documentation.

After two additional weeks, the project grades were published. Mine was 90. I was thrilled. “I guess I’ve really done a great work”, I told myself. I was so proud that I decided to take the hard copy I had submitted and keep it. So I did. The minute I took it, however, I realized it had never been read. The folder I had submitted remained unopened. All the pages remained just as I’d printed them; there was not a single mark or comment. No “great work!”; no “Have you considered…”; no “it would have been better to use…”; nothing.

I started to wonder what was wrong with my project. I didn’t have as much as a single comment to learn from. So I went to meet my instructor. He gave me a bored look and said: “your program’s output had a couple of typos here and there. The script we used to check the exercise identified them easily. I don’t know what we would have done without it.”

The message was loud and clear: “We care only about the immediate bottom line”. No one said I should not design, plan and make my code readable. But I wasn’t going to learn and improve my skills by doing so, and I wasn’t going to be appreciated for the effort.

What Does It Mean To Be a Professional?

Everybody seems to be looking for professionals. At least that’s what everybody is saying. With the ever-growing development costs and the increasing complexity of projects, you cannot afford settling for less.

Some organizations (too few if you ask me) seem to start realizing that the way they are currently developing software will not meet these increasing needs for long. They know they have to do something about it, and the most natural solution seems to be hiring professional employees, or sharpening the skills of their own employees.

At the same time there are some initiatives to certify software development professions such as software developers, testing engineers, etc. The idea at the basis of these attempts is to make these professions more mature, and increase the quality of software products throughout the industry.

But what does it mean to be a professional? Is the essence of being a professional lies in some sort of a certification process?

A professional developer (and by that I refer to everybody who takes part in the development of a software product) is someone who has the ability to maximize the value of her work and minimize the cost this work imposes on the organization.

A professional developer always walks this thin line between cost and value. Allegedly reducing the immediate development costs by storming into development without any planning, analysis and design is bound to inflict a severe cost almost instantly. Taking a substantial amount of time for considering each and every little detail in the product’s design is also not cost effective in many cases. A true professional knows how to balance these forces and optimize the way she creates the product.

To make the right choices, a professional developer must have extensive knowledge and experience. She should also be aware of quality and accept her responsibility for achieving it. She should have the right mindset and an in-depth understanding of the consequences of her decisions. A professional developer must have an intuition to help her apply her experience and knowledge in different contexts.

All these qualities are personal qualities. They are qualities of the individual. However, one important force has a tremendous impact on the ability of people to perform their job professionally. This force can prevent them from exercising their professional skills or encourage them to acquire new skills. It can drive people to grow as professionals or drive them away from taking responsibility for their actions. This immense force is the organizational culture they work in.

Here is the paradox. While many organizations are constantly looking for professionals, only few are really encouraging professionalism and enabling it. Many of them do the opposite.

The Organizational Subtext

We are motivated creatures. Whatever we do is the result of some kind of motivation, either internal or external. Although not every decision we make is the right one, we seldom make arbitrary decisions.

In our “professional” lives, the environment we work in has a tremendous effect on the way we act. In fact, the organization we work for is probably the ultimate factor in any “professional” decision we make. After all, our success depends on the success of the organization, and “the organization” is the one outlining the strategy for success.

So, you are a software developer trying to understand what professionalism is all about. Why? Because professionals are appreciated, compensated and being promoted, aren’t they? You work in what seems to be a successful company. No one explicitly tells you what you should do to be considered a professional. So you start looking around you. You see people who are managing projects, which are never delivered on time; you see people developing products with no clear vision; you see people working ruthlessly on several projects simultaneously, having to cut corners to be able to juggle their tasks fast enough. And above all, you see all these people being promoted, appreciated for their effort, and announced as valuable assets of the organization.

Soon, you start to get the message. You might not be doing it consciously, but chances are you will start aligning with the organizational subtext. If your organization appreciates people working long hours, trying to deal with crises they should have prevented – so be it. If working on multiple projects at the same time is considered professionalism – you should probably try to improve your multitasking skills. If management promotes people who quietly comply with the current development practices instead of constantly seeking ways to improve them – why should you take a chance against all odds?

Don’t underestimate the influence of the organization over people. I’ve seen many developers who had what it takes to be professionals. With some guidance they could have brought great value to the company they work for. But they were encouraged (if not forced) to choose a different path.

The influence of the organizational subtext is so great that many employees start to adopt it as their own. When I talk to developers and managers, I often hear them repeat some common mantras. “Multitasking is the nature of software development”. “We must be competitive and be the first on the market, so we don’t have time to do things by the book”. “Our customers don’t care about quality – they just want something they can use on time”. “We will always have time to fix these problems later”. “Why bother with unit testing – this is what we have QC for”. And my personal favorite: “In business the next quarter is all that counts!”.

None of these myths has anything to do with being a professional. No one learns these “truths” at college. No one gets this impression from the professional literature. And still, this is how most people in the software industry perceive the essence of being a professional. Where does this perception come from?

The answer is simple. This perception is part of the organizational subtext these developers and managers have adapted. These are the messages they are exposed to on a daily basis.

Introducing a New Subtext

Creating a new organizational subtext is not a theoretical vision. It won’t happen overnight, but it can happen. Almost no material investment is needed. All you need is to change the organization’s mindset. In the business world, this means changing management’s mindset.

This sounds somewhat abstract. So let’s be more concrete. Many things can make a change to the organizational mindset, but I think you can start with three: a professional vision, a culture of mentoring, and accountability. When applied seriously, these three concepts can make a significant change in any organization. Even in yours.

Professional Vision

Professionalism cannot exist without a vision.

Every company has some kind of mission statement. Most of them refer to world dominance, serving customers, making more money, etc. These might be good mission statements for analysts. They do not mean a thing, however, to the technical staff. Well maybe they do mean something, but they sure won’t help the technical staff understand how to do their job professionally.

A professional vision is like a lighthouse for the technical staff. It should guide them in their day-to-day work and show them the general direction. A clearly articulated professional vision sends a message across the organization: this is what we expect you to achieve, and you will get our full support in trying to do so.

Don’t confuse a professional vision with a technological one. A technological vision concerns the technological roadmap of the organization: delivering the next generation of operating systems, creating a search engine that will index all the information in the world, etc. A professional vision, on the other hand, expresses the professional code of conduct: writing maintainable code, creating designs that enable easy change and extension, shortening integration time – anything reflecting the expectations of the organization from its professional workers.

Having a professional vision in some dusty document is meaningless. In order to be effective, management must articulate this vision on every occasion. Everyone in the organization must understand that the success of the organization depends on the implementation of that vision. Without true management commitment to a professional vision, it will soon be forgotten.

Professional Mentoring

After setting the goals in the form of a professional vision, management must provide the technical staff with a way to achieve it.

The majority of people are not born professionals. They have to gain sufficient knowledge and experience in order to become ones. At the same time, the nature of software development professions is mostly context sensitive.  This fact makes the task of becoming a professional extremely challenging.

Learning software development professions from books, courses and presentations will never teach you how to correctly consider the different tradeoffs, forces and constraints in a given context. In order to master these domains and become a professional, you have to develop intuition. You have to have the experience to enable you to correctly apply knowledge in context.

The key to gaining these skills is ongoing professional mentoring. When a professional mentor works with her mentee in the context of her day-to-day work, the mentee can build her experience in a guided manner. The mentee builds her experience and knowledge based on real-world problems, constraints and forces, and she immediately applies what she learns in her work.

From the organization’s perspective, this is a sure investment. On the one hand, this investment will help nurture the next generation of professionals. With their new skills, these people will be more valuable to the organization. But, since mentoring is done in the context of live projects, the products developed today are also significantly improved. Every dollar the organization invests in professional mentoring immediately pays off.

Without providing the technical staff the facilities to grow and become professionals, no organization can expect them to meet its professional vision.

Accountability

A few years ago, I was the development project manager of a small-scale project. It should have been a simple project, with no apparent risks or pitfalls. The problem was that the architect of the project kept changing the interfaces between the two components involved in the process. Some of the changes were small, others were more significant, but they always came in a bad moment. No matter how many meetings we had on the subject, the interfaces just wouldn’t remain fixed for more than a week.

From the architect’s perspective these were really minor changes. For us, each such change required a fix in the code, a fix in the relevant test cases, and a fix in the simulators used to test the components - not too much trouble when done once, but when done almost on a weekly basis this practice became quite a pain.

Here’s the nice part of the story. When the project had come to completion, it was immediately announced across the organization as a success: the perfect project. I knew it wasn’t. Everybody else involved in the project knew it wasn’t. But that didn’t seem to bother any one. This project was not the first one to face such problems, and it certainly wasn’t going to be the last. Years later projects still suffered from the same interface instability problem.

Having a professional vision and providing a way to exercise it are huge steps towards being a professional organization. The one thing missing from this picture is a culture of accountability.

Accountability means being responsible for the decisions you make and the job you perform. If the organization leaves that to the good will and conscience of its workers and managers – most of them will not consider themselves responsible for the things they do.

If there is no recognition what so ever in failed projects, significant bugs, design flaws, or bad planning, most people will realize that what they do and how they do it don’t really matter.

Does accountability mean people should be fired for making a bad decision? Does it mean people who made mistakes will never be promoted? Absolutely not! This will not promote professionalism. Instead, it will create an atmosphere of fear. No one will take any chances or make brave decisions. And without taking some calculated chances, no organization can succeed.

So what does accountability mean? It means that when a decision proves to be wrong, or when a task seems to be implemented unprofessionally, whoever made the decision or implemented the task will take responsibility. Taking responsibility in that context means trying to figure out what went wrong and openly sharing these insights with peers, managers, and subordinates.

Maybe the decision was the right one, and the same risk should be taken in similar situations in the future. Maybe the course of action was wrong because the owner of the task failed to consider all the relevant factors. In any case, sharing this analysis with colleagues throughout the organization will help them learn and make better decisions in the future. 

The person accountable for a task or a decision is not to blame in case of a problem. The essence of accountability is helping others avoid the similar problems in the future. This kind of accountability can only be effective when applied across the organization. For this to happen, management must demand it and encourage it.

Accountability promotes professionalism in two aspects. First, professionals should take responsibility for their actions. Second, professionals are constantly learning from their mistakes and the mistakes of their colleagues. Without a culture of accountability, none of these can take place.

The Professional Organization

The professionalism of developers, testers, project managers, architects, team leaders and others is tightly coupled with the organizational subtext in which they operate. No efforts to standardize and certify these professions can make a real difference without a supportive organizational culture. At the end of the day, each of these practitioners is more likely to align with the code of conduct she is familiar with in her day-to-day work.

Any change in the way people perform their job must be motivated, supported, and nurtured by the organization they are part of. For your employees to be professionals, your organization must be a professional organization too.

A professional organization must articulate a professional vision. A professional organization must teach its employees how to achieve that vision. A professional organization must encourage people at all levels to take responsibility for their actions and help others learn from their successes as well as from their mistakes.

A professional organization is the best place for individual professionalism to grow in.

Epilogue

One month after the conversation with my instructor, I already found myself a job. A real job in the real world, where I could learn and grow. I continued my studies, because I thought the degree would come in handy. But my mind was already somewhere else.

I was excited to receive my first real-world assignment. I did my best to write it as good as I could, but I wasn’t fooling myself. I knew I had so much more to learn about good design and coding (for me this was the essence of software development back then). So the minute I thought I had finished my task I sent the code to my boss for review. I was eager to get a professional feedback on my work.

My boss’ response arrived soon after.  “We really have to go through your code together. You have some typos here and there”.

Dedicated to those who insist on their right and duty to be professionals.

References

• The Lucid Quality Approach: http://www.lucidquality.com
• The Quality Within: http://www.qualityaspect.com/Books/TheQualityWithin/