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

Long Meetings

On Friday we spent a long time in our Sprint Retrospective meeting discussing the problem of spending far too much time in meetings. The irony was not lost on us.

The outcome was that we should not spend so long in meetings, keeping the meetings short and focussed. This means more investigation and analysis beforehand so that the team members are prepared for the meetings with sufficient information.

Midget Project Failure

Some time ago I owned an MG Midget that I'd decided to restore.

I started with high hopes - expecting to complete the restoration project in a few months so that I'd be back on the road again by the following Summer. Events, as is often the case, took a somewhat different course.

Everything felt like it was starting off fine, though the breaking up of the old body shell would have benefitted from the use of better tools to speed things along, such as using a generator and power tools to cut up the pieces, rather than hand tools and brute force.

Fitting of the rear springs went well, but I'd not bought the right size of thread taps, so had to move a smaller-sized tap around inside the captive nuts to tap them, clearing away the paint. Using the right size of thread tap from the start would have made the task easier, and I would have been more confident that the threads were tapped cleanly and correctly.

Each of the parts to be refitted to the new body shell was cleaned down, de-rusted and re-painted. Unfortunately, not all of the de-rusting was 100% successful, and there were areas of rust that reappeared through the new paint. Also, the new paint was not always as tough a finish as I'd have liked. Meanwhile, these restored components were gradually refitted to the new body shell throughout the Winter and Spring.

So, I should really have improved on my de-rusting techniques, ensuring that they were completely successful in order to prevent me from having to do the same work to them again, but after having to remove them from the car. Similarly, I should really have improved on my re-painting techniques to ensure that the items were painted well, and that they had a tough, durable finish.

Also, did all refitted items have to be de-rusted at that point? Could they have been fitted in order to facilitate getting the car back onto the road and then restored later on?

Similarly, did all the items have to be fitted during the Winter and Spring? There was less natural light during those months, and the air was damp. If I'd prepared the parts to be fitted, and saved them up to fit them in late Spring and Summer the air would have been dry and the light better, giving me better visibility for the job, and less chance of trapping moisture that would cause rust later.

Whilst I was cleaning down and de-rusting the old parts, I saw how some components could be modified to improve the overall result - upgrading to newer parts, installing additional gauges, upgrading the suspension, modifying parts. Again, did these all have to be done at that time? Admittedly these were the exciting things, rather than the regular restoration, but they were a distraction from the goal.

Though, what was my goal? Was it to get the car running again by summer? Was it to perform a concourse-level restoration? Was it to perform an good restoration and to improve the car to my own specification? Admittedly, the goal was unclear, and the lack of clear objectives distracted me.

As the months went by, they turned into years. I changed jobs, and had less time to devote to the restoration project. Then the enthusiasm went - there was no real result for all those years of effort. The car may have been 90% complete, but the last 10% was feeling far from achievable. Doubts also began to creep in, with me worrying about whether I had done a good job on the car in the early stages, particularly on the vital structural pieces. These doubts were also fuelled by the fact that various adjustments had to be made to get pieces to (almost) fit into place.

Eventually I realised that I just did not have the time to complete the project, and I did not have the inclination either. So, away the car went, sold as an incomplete restoration project.

I learned a great deal from the experience, and not just about bolting parts together.

I learned that this project had failed because of a failure of project management.

• The goals were unclear - car on the road by the Summer, or car restored to concourse style?


• The un-clear goals meant that there was no clear plan. With no clear plan there was scope creep - in came all the little "nice to haves"; those shiny parts and new instruments. Without a clear plan there was no clear schedule for preparing parts in Winter and fitting them in the dry and light of the Summer.


• Quality control was not clear from the outset. There was no clearly defined quality standard for the use of the right tools, and the quality of the restored parts being refitted. If quality control is not established from the beginning, then it means that extra work is required to be undertaken later on to verify and/or correct earlier quality issues.


• The unclear goals meant that there were no clear deliverables. There were no iterations identified for getting the car on the road (almost as a working prototype) then building up from there with the additional features. An iterative approach would also have boosted my confidence with my project-sponsor's hat on and boosted my confidence with my project worker's hat on

So, there I left a failed project, but I came out of the experience wiser.

Magyar Muddle

I'm in a dilemma over Hungarian notation.

Should I use it or not?

My intuition says, “No.” But various coding styles where I work suggest using it.

However, I’m drawn towards it for web form controls, but only ever so slightly, and it was a long time ago that I formed that opinion. Since then my feelings on variable-naming have annealed.

Using an IDE such as Visual Studio and programming in C# which is strongly-typed, there is no need to signify the type of a variable in its name. The IDE ensures that only the correct operations are performed on the variable for its type.

There is also the inherent contradiction in coding styles that use Hungarian notation for types in the .Net framework System namespace, but not for other classes in other namespaces.

In a weakly-typed language, using Hungarian notation is a great help in reducing errors because there is no IDE to stop you adding a variable representing a Boolean value in one scenario to a variable representing a series of digits in another scenario.

Though I’m also drawn to using Hungarian notation for the same fundamental data but represented in different data types, such as when a number is represented as a String and an Int32 in two different variables. I can live with this as a contradiction because it is a rule designed to seek clarity with the basic non-Hungarian standard.

So, my feelings on Hungarian notation are:

In weakly-typed languages, use Hungarian notation.

In strongly-typed languages, do not use Hungarian notation, except when the same fundamental entity is being represented by variables of different types.

Now I just have to convince others...