Officially an Engineer

With all the paperwork completed, I am now officially a Chartered Engineer.

So the letters CEng now get added after my name, which means my CV gets updated again, just like when I acquired the post-nominals CITP.

This doesn't mean that I can now go around saying that I can build roads and bridges - in fact it means that one of my professional duties is to not say that I can do things which I am not qualified to do. What it does mean is that I am recognised by my peers as a professional engineer who applies engineering discipline to the practice of software engineering.

Degrees of Experience

I chose my undergraduate degree course because it was ranked the number 1 computing course by British employers. After all these years, does what I was taught in that course serve me today?

I studied Computer Science, not Software Engineering. My work in industry has very little science about it, and more to do with engineering and project management.

I was not taught how to write "good" code, only correct code that satisfies functional requirements.

Similarly, I was not taught the benefits of database de-normalisation in a practical environment.

This is the craft vs science paradox. I was taught the science of computing, but the real-world day-to-day application was missing.

OK, I might be a bit harsh in saying the real-world application was missing. After all, I got by writing poorly engineered code for a long time, and so have many others, and even more still do. Also, this was 20 years ago, and things may have changed in the last 2 decades.

Aspect Oriented Programming (AOP) was unheard of.

Design patterns were still to be popularised by the gang of four.

The web was still to be invented, though the Internet was around with plenty of e-mail, usenet and FTP activity.

It is reasuring to read that Bjarne Stroustrup (he of C++ fame) teaches at Texas A&M University's Department of Computer Science a course on Advanced Programming Techniques which addresses the issue of:

writing code to be used and maintained by others than its implementers

which also includes a group project, hence requiring student programmers to collaborate as a team.

Though today I find that the two biggest skills sought by employers (at least for enterprise software) are:
understanding of an Integrated Development Environment (IDE) e.g. Visual Studio in whatever version;
familiarity with framework code libraries such as .NET

The days of the hero coder with his specialised weapons of only a simple editor and his knowledge of algorithms are long gone. There are common tools now and infantry coders rely on an industry of standard munitions.

Now a Professional

I'm now a Chartered IT Professional, so I can now add the letters CITP after my name.

Despite this latest award I've not quite achieved my ambition of having more letters after my name than in my name. But if I include the spaces then I have equalled the length of my name.

Upon receiving the news I thought, "Great! How do I update my CV now?"

OK, so I put CITP after my name, but I now need a new section for awards as it does not really sit well in the Certification section, which is more geared towards course-based material. After all, that's the whole point of acquiring these qualifications, isn't it?

The BCS says that as a Chartered IT Professional you should gain more credibility with employers and a competitive edge over your peers, helping you to advance your career more effectively. BCS campaigns with employers to recognise CITP status as the benchmark for highly skilled and committed IT professionals.

Whilst that is a noble goal, I fail to see it happening at the moment. On the one hand, not many organisations will have heard of the British Computer Society. On the other hand, of those that have heard of the BCS, only a few will have heard of Chartered IT Professionals.

So why did I seek out this extra award?

Well, I believe that professionalism in IT is all too often lacking, and that we need to put the "engineering" into Software Engineering.

If Civil Engineering was like Software Engineering we would have bridges built late, over budget and not meeting the customer requirements. They would also collapse frequently, need upgrading regularly, and would often be closed for servicing. And that is just for the few that would actually get built.

Would you hire an unqualified lawyer? Doctor? Accountant?

Then why do people hire self-made/amateur IT staff with no professional qualifications?

Would you hire a bricklayer who's only building experience is some DIY at home? Then why hire IT staff whose only experience is a bit of scripting and coding at home? (Having done plenty of DIY bricklaying myself, which I find quite satisfying, I would still rather hire a professional bricklayer for anything but the most basic job.)

For the last few years I have been very much quality focused, pushing for the adoption of:

• coding standards
• SQL standards
• design patterns
• test-driven development
• continuous integration
• peer-review
• well-defined processes

The sad thing is that in each team I work with I have to establish these (what seem to me) basic practices.

Each team I've worked in I've said that anyone other than a tester is an amateur tester, and all too often I have not had professional testers to draw on.

Or maybe I'm thinking about this the wrong way, and that it's really a matter of Gentlemen and Players? Whilst the notion of the gentleman athlete is romantic, it is exceedingly out-dated, and has long been surpassed by the professional player.

Lack of Ownership

To break the old way of thinking I kept hammering home the message with my team that:
"You do not own the product/requirements"

Unfortunately, this became interpreted as:
"You have no responsibility or stake"

By breaking down the old way of thinking, I had not replaced it with something else.

The team felt that they were just randomly picking tasks from the scrum board each morning.

(A clue should have been the fact that it was taking so long at each daily scrum for people to choose their tasks. This showed that people were un-prepared for deciding what they would do that day.)

How to Tell a Horse to Drink?

I had a very revealing and productive 1:1 meeting with one of my development team this afternoon. I'd set aside an hour at the end of the day instead of the usual half-hour slot for our monthly 1:1 meetings; instead, the meeting lasted two hours.

Ever since I arrived in my current position I told the team, in true Scrum fashion, that they were self-organising, with the mantra "let the team decide".

Unfortunately, the team had not really grasped what the true implications were.

This was a lack of communication on my part, and not devoting sufficient attention to coaching the team in how to think in agile ways and seeing how they interact.

There had been several misunderstandings over the concept of "ownership". Telling the team that they did not "own" the products left them feeling that they had little or no stake in them. In order to clarify things I had to say that the team does not own: the requirement for a feature, the prioritisation of a feature or the business value of a feature. However, the team does own: the responsibility for committing to, and delivering on, the solution to a requirement; the technical architecture of the solution to a requirement; and, the processes for delivering solutions to requirements.

My previous experience had been that the team would spontaneously self-organise in order to drive requirements to completion. In an Asian context, developers are not accustomed to being allowed to think for themselves: designs are handed-out, tasks are assigned, people do what they are told.

The team did not realise, despite them being told that they are self-organising, that they can have individuals in the team who drive forward the delivery of the solutions to requirements. Now I ensure that the "driver" for each requirement is identified at the end of a Sprint Planning Meeting - how a driver is identified is not prescribed: people can volunteer, I can make a suggestion, I can say that someone should be the driver. The difference is that with a named driver the team feels a greater sense of ownership of the delivery of the solution to a requirement. Maybe one day they will be a little more pro-active in terms of the self-organisation...

The principle of whole-team involvement was also taken too literally, and did not respect the capabilities of individuals. Each team member has his own strengths, weaknesses and aspirations. Whilst some are good at one thing, others are not so good at it - the team should be able to recognise that and act accordingly. The response can be to use the strengths of the individuals directly by them doing things themselves, or indirectly by them guiding or assisting someone else who wants to develop their strengths in that area. How the team had reacted was to assume that everybody was equal (which in some cases they are, such as when voting during estimation in Sprint Planning meetings, and being able to contribute to discussions) and that everybody was expected to do equal work. The emphasis on the removal of single-points-of-failure may have contributed to this attitude, though the drive to remove single-points-of-failure is still on-going.

In terms of agile design and delivery, despite repeated instructions to break large requirements down into iterations and to concentrate on designing the minimum amount in the beginning, and only designing in any kind of detail for immediate (highest priority) requirements, we still ended up tending towards a waterfall design approach.

More involvement in the design process to coach the team to think in iterative and agile ways seems to be putting them back on track - though there are still times when the team risks falling into paralysis by analysis rather than seeking clarification from outside the team.

After careful and persistent questioning, I also managed to get my developer to provide some feedback on me in the 1:1 meeting. So far, I've been inviting my team members to tell me their concerns and problems in our 1:1 meetings so that issues can then be resolved. The 1:1 meetings aim to be a two-way conversation where either party is free to say what they want. Instead, everybody has just been saying that everything is fine and that they are happy how things are going.

However, I'd learned that the team had expressed some misgivings about things to higher management.

So, with a little more humility than usual, a lot of in-depth questioning to get him to open-up more to me, and some straightforward asking of what he thought about me I managed to get some much more honest feedback.

To my surprise I learned that my team can consider me to be intimidating.

My sarcasm does not always travel well, and can be misinterpreted. I also do not like arguing for argument's sake, but will play the Devil's Advocate in order to help people probe their own arguments further, or I will argue my point if I hold by own contrary opinion - this can be interpreted as being aggressive. A constant stream of criticism, though well-intended as my continual drive to improve quality, can also be demoralising.

However, I am conscious that I had been praising good work.

My developer has now gone away with the message that honest feedback is welcomed, and that if anything is affecting communication then that is an impediment to the team achieving its goals of delivering well-designed, high-quality software in a timely fashion, and as an impediment it must be resolved.

How to Succeed as a Manager

Over the years I have witnessed various managers at work and practised various management activities. Here are some of the tips that I have found to be successful:

Telephone etiquette:

1. Answer your mobile phone during meetings, especially if people are waiting for you to say something - the people in the meeting are already there so they will wait for you
2. When on the phone go and stand next to someone else's work area and talk loudly - remember that whatever you have to say is important

E-mail etiquette:

1. When sending out an e-mail, go and talk to the recipient to tell him about the subject before he's even noticed the e-mail arrive - under no circumstances mention that you have already sent the same information by e-mail
2. When referring to website links in your e-mail never include the actual link - that would take up far too much of your time (which is worth more than everyone else's) so get all the recipients to track down the link instead (even if you had it open in front of you)
3. When asking for something, do not give a justification or a required date - everything is required ASAP and because you ask for it, it's needed

One-to-one meetings:

1. Only schedule one-to-one meetings with your subordinate managers after a few months in the job, and after your boss reminds you that you should be doing that - but do remember to request regular one-to-one meetings with your boss within the first few days because maintaining the relationship between you and your boss is what matters
2. Repeatedly cancel or reschedule one-to-one meetings with your subordinate managers - your subordinate managers will then understand that you're really very busy and see where they sit in the hierarchy
3. Do not tell your subordinate managers the agenda for your one-to-one meetings until after several weeks have passed - then complain that he is unprepared
4. When you do have an agenda, the format should be: the subordinate reports progress to you, you tell the subordinate about initiatives
5. If you have any comments about your subordinate manager's team suggest they work longer hours - do not offer any other suggestions at all

Performance objectives:

1. When it's time for the coming year's performance objectives to be set, call every one of your subordinates and their teams to a meeting to give a high-level overview of the department's objectives, but do not indicate how those objectives translate to your teams
2. Let your subordinate managers spend a great deal of time and effort setting detailed and focussed objectives for their teams, then tell them that you want objectives to be project-based rather than role-based - after all, they are only junior managers who should not have their own agendas for their teams (which are actually your teams)
3. When your subordinate manager asks you seek clarification from your boss, say that your boss prefers project-based objectives, even though he prefers role-based objectives (and had had the same argument with his own boss previously)

Managing development partners:

1. Tell development partners that you don't want to micromanage them, then tell them in the same breath that you want them to work in a particular way
2. Tell development partners that you don't like their development estimates, even when they show you all the calculations - this also applies to estimates made by your development manager's team (sorry, your team of developers)

Supporting the hierarchy:

1. If one of your subordinate managers holds a contrary opinion to you, argue against his position and refuse to budge
2. If your boss holds the same opinion as your subordinate manager against whom you argued so intransigently, agree with your boss
3. When telling your subordinate manager to do a particular task rather than delegate it to a team member, tell him that he should do it because of his seniority - do not suggest that someone should do something because of their ability

Meetings:

1. Join in technical conference calls with one of your subordinate first line managers' teams , then once you can think of no more questions say "I think that's all the team need to know" - remember that you know better than anyone of your subordinates what they need to know
2. If a point's worth making, keeping making it, on and on until people's eyes start glazing over - even if the point's not worth making, make it anyway, and hammer it home until it's gone right through people's heads and they ignore what you're saying

Race:

1. Tell your Caucasian subordinate manager that Asian managers have an ability to look at problems in detail, unlike Caucasian who can only look at higher-level management issues

Information flow:

1. Do not under any circumstances read anything written by your subordinate managers, this includes details of team processes, project progress, etc.
2. Insist on holding a meeting with your subordinate manager for him to tell you things that he has already published on his team's wiki site, or is displayed for all to see on a Scrum task board

Communication:

1. If someone complains that they were not informed of something then reply "It was perfectly clear to me what I said"
2. When finding out about a bug in order to prioritise it, do not record any of the information you discover in the bug tracker, leave that to someone else, then say that there was no extra information to record anyway - stare blankly in disbelief at anyone who dares say that having talked to someone and received no extra information is in itself valuable information
3. When you have a question, go and interrupt someone else right away, no matter whether they are already in the middle of their own meeting - you have to let people know just how important your work is compared to others
4. When someone uploads a series of files to a location and you want to know if a particular file is there, do not go and have a look at the files, instead ask the person who uploaded the files in the first place

Understanding of the software development process:

1. Developers are to do everything - testing, bug fixing for code written by outsourced partners, providing desktop and application support for you
2. Do not find out what processes your subordinate development manager has established - particularly if they are written down (remember that written down information is not to be read, especially if it is written by a subordinate)
3. Do not support your subordinate development manager's repeated request for testers - developers can do that anyway
4. Do not bother to learn the difference between unit testing and functional testing

Supporting change:

1. When asked about doing something better than it is done at the moment, reply that you'd like to do it "in an ideal world" - then give no indication that you will do anything towards reaching that ideal world, let alone actually do anything about it

It's your team:

1. When starting as a middle manager, tell your subordinate first line manager's team how to do their jobs - do not under any circumstances discuss or confide with the first line manager
2. Go directly to your subordinate first line manager's team members with requests and status updates - do not under any circumstances approach or inform the subordinate first line managers
3. Do not forget that your subordinate managers and their (your) teams are there to support you - your are not there to support them

Finally:

1. Suck up to your boss, and suck up harder to his boss
2. Never apologise or admit to ever having made a mistake - it only shows weakness and fallibility