I’ve been doing quite a few interviews recently, and I am being asked a lot about team management as expected, but unexpectedly the majority of the answers that people are looking for are based around the core need to not hire a self centred horror and get someone who can help and support a team or project to hit deliverables.

This should be an absolute base line, but as it does not seem to be, here are the 6 most BASIC tips I implement when working as a team or department lead from the perspective of the people you are responsible for:

1. Learn International public holidays. This is a simple one. Go to Google calendar or any major web calendar and load all of the public holidays for the countries of all people that you are responsible for, Learn the public holidays and do not be surprised when someone is not working that day, Bonus points if you can pronounce them and learn their relative importance in the year.
2. Never use any variation of “Well if I’m in, you should be in as well” responsibility and work are nearly always linked to remuneration, or to put it more simply, you tend to be paid more than they are so they are not supposed to be doing as much as you.
3. Don’t pit yourself against the more important real life things. Your monthly report is not more important than their only child’s graduation. Use your judgment rather than your ego.
4. Learn to handle the truth. Anybody who is responsible to you should be able to bring you any related problem in confidence that you will work to make it better, you might be upset, you might even utter a few swear words, but you must not aim it at them, this is now a shared problem and your goal is to help them and to solve it. Do not scream at them, do not take out your anger, fear or whatever on them. They have brought you the truth, If you freak out no one will bring you the truth again. You will have proved yourself incapable of handling it.
5. Do not allow familiarity to breed contempt, This is quite a common one. Someone does something amazing and everyone is impressed, but the next time they go that extra mile, people are less impressed and they get less praise, so now there’s now less reason for them to go above an beyond. Judge each time someone is amazing as a stand alone action, and if they do it a lot promote them or provide a longer term reward.
6. Most importantly never ever, EVER throw them under a bus, you must stand in front of your team or department and take the hit if there is a major issue. after the problem as been resolved there might be repercussions internally, but you stand united and you back them during the time of the crisis against a third party.

When you have a large scale project that just feels stuck, where nothing’s moving, where everything is a constant battle just to make the smallest progress it can be very frustrating.

But ultimately as an architect you need to get it sorted. It just might mean you’re battling on too many fronts, the solution to this is to focus down to individual issues, as I was once taught

“it’s how you kill a zombie horde, one half brick in the head at a time”

and this works. In fact, it’s exactly the same method as people deal with overwhelming personal debt. You pick the biggest, most painful item and concentrate your full attention on it. break it, beat it, do not get distracted.

Once you’ve beaten that one. Then you move to the second most awkward one and again put your full concentration on it, and work your way through like this till the project as a whole starts to move again, if you’re dealing with real people this form of action builds up momentum, problems that were just made up issues before suddenly melt away because people do not want a projects full attention on them, and issues that were genuine welcome you, as they think you are bringing real help, even if its just a half brick and a grim expression. 

Disclaimer: As always these posts are not aimed at anyone client or employer and are just my personal observations over a lifetime of dealing with both management and frontline associates.

This is an odd little tip but it’s one that has stood me in good stead over the years.

Sometimes when you’re talking to a senior stakeholder, they see things from what they often say is ‘50,000 feet” which gives them a very broad view of challenges, and from a strategic perspective gives them a better idea of how to solve things, but can at a tactical or small scale actually cause a lot of grief.

Trying to explain that without inducing a dismissive response is actually quite challenging. It’s often either “just get over it” or “this is our strategic view”, and to have an example of how such a strategic view is actually worse for a given project is challenging. The one example I found that worked is related to a military feature ¹:

A salient², is a battlefield feature that projects into enemy territory. and if you look down on one from above they all look the same, however the solution is different depending on their size.

If they are huge in scale, then you can “bite” or “Nip” them off, which cuts a load of troops of in a position where they are surrounded and cant get any support.

However if they are small, say for this example a trench in world war I, then they just expose the enemy to being shot at from all sides which is great, but also attempting to “bite” them off costs a load of your people while making the enemies life easier.

Generals of the era treated both sizes of Salient in exactly the same way, that is, the large scale strategic way that they had been taught, this lead to many, many needless deaths, and gave away many a tactical level advantage.

So I know that this example sounds a bit contrived, but I have found that when dealing with senior stakeholders, grander examples hit home better, and hopefully it will convince them that sometimes a tactical solution works where a strategic one will not.

1. Something few senior stakeholders can resist[↩]
2. , also known as a bulge[↩]

Workshops or the simple act of sitting down with the client or customer in a single room and thrashing out a problem are absolutely invaluable in any decent sized project.

They are a necessity both for actually getting the feel of a given bit of work and figuring out local issues ¹, to building rapport with the business so they know that you’re all on the same side when trying to deliver.
The only thing is, timing. The human element of a workshop, the rapport side of it demands that we should do them straight out the gate, to provide a good first impression, “we are your kind of people.” “Tell us what you need, and how we can help.”, all that kind of stuff dictates that you should do a workshop first thing in a project.

But from a technical and practical side this does not work, because you haven’t turned over all the rocks and looked under them, everyone is fresh to the project and enthusiastic, however very little of the true cost or issues that a project is going to face will come up now, and frankly from a moral and engagement point of view you don’t want the cynical techs raising such points in initial calls.
This is one of the reasons why when you have large consulting houses come in and do an evaluation of an infrastructure or what have you, they always miss things. It’s not their fault, things simply have not been found.

You need to go down into the project’s dependant systems, turn over every rock, find the real people who are doing things rather than the people who were introduced as in charge, find all the nooks and crannies where the Dragons be, before you actually have a true visualisation of any existing system or processes.

So, when I’m doing large scale projects, I would recommend two sets of workshops. An initial workshop that is human focused, that develops rapport, and gives initial starting positions and works out where people hope to end up.

Then further down the project timeline, book in a review workshop, or “step back” workshop to be done once you’ve had a few months in, and the techs have had a chance to talk to each other, you’ve had a chance to thrash out real processes, found those hidden systems that everyone had forgotten about. Found out the people that do all the little manual interventions to make a process run in the real world

After that, put those into the project plan and cater for any knock back they will cause. This is the crucial point, you will have planned for these knock backs and timing changes up front, this gives the client the appreciation and understanding that you have been down this road before, you know that this is what’s going to happen, can predict it and roll with it to still deliver on time, and should you do the review workshop and don’t find anything new, then it can be used as a back patting exercise for the client, shows everyone how well they knew their stuff to start with, and how pleasurable they are to work with.

So yes, I would always include two sets of workshops.

1. if it’s a large international corporation[↩]