How early-career architects become good at working for other people - Part 1

Photo by Kelly Sikkema on Unsplash

An examination of your role in carrying out tasks for other people

In this four-part post, I’m going to use some simple case studies to show you that, if you’re serious about becoming a good architect, learning how to work effectively for other people is a vital skill that you’ll need to develop.

I know you didn’t decide to be an architect in order to work under someone else’s direction, but it’s what most of us do most of the time.

The skill of working for other people isn’t discussed much, either in schools of architecture or practice, so I’d like to give you some guidance. You may not have considered it a skill before, but I hope to show you that it is.

This introductory post, which is a 12-minute read, will cover the following topics:

• When you first start work

• Are you working ‘with them’ or ‘for them’?

• Delegation, but from your perspective

• Even a simple task can be complicated

• Dealing with the complexity of the situation

• Self-directed work vs working in a team

• Summary

Future posts will cover:

• Part 2: What happens when you know how to do the task?

• Part 3: What happens when learning is involved?

• Part 4: A checklist of things to think about and things you need to do

When you first start work

When you first start work, you will be doing things for other people.

That’s inevitable.

There may be some things that you can get on and do, such as aspects of drawing or computer graphics or model-making, but even if you can do the required task, you will do it to someone else’s requirements.

And anyway, the whole point of your early years is to gain experience in things that you haven’t done before. That’s how your real development is going to happen. This means that you’ll be doing things that other people have deemed necessary and doing them under their direction.

At architecture school, you probably spent a lot of time doing studio projects on your own. You may have done a small number of projects within a team of equals, but it’s possible you won’t have worked under someone else’s direction before.

It sounds like such an easy thing to do. Someone in a position of responsibility, such as the project architect or a director, tells you what needs doing, and you do it. If you haven’t done a particular task before, you’re given some instruction or training, and then you do it. Simple.

Unsurprisingly, reality turns out to be more complicated. Other factors, such as the personalities of the people involved, the way in which the task is communicated, or a misunderstanding of the objectives, can all contribute to things going wrong.

Therefore, how you approach your role in working for other people requires some careful consideration.

Are you working ‘with them’ or ‘for them’?

I've spent my whole career working in teams. I believe in the effectiveness of teams, particularly when people are allowed to do appropriate tasks based on their abilities and aptitudes.

Given that I am biased towards a team approach, it would have been tempting to talk about 'working with' rather than 'working for' other people. The former term would have emphasised the idea of a harmonious team and its non-hierarchical nature.

In reality, teams are not like that, and there is always a hierarchy. Teams need a leader to provide direction, and there may be other strategic roles that other members of the team play. Some people will be regarded as experts in certain fields because of their experience and skills. A team works according to some declared structural hierarchies and others that are unspoken and based on the natural order of things.

I've chosen to use the term 'working for' because it reflects reality better, even though it doesn't sound quite as democratic as you or I might like. As an architectural assistant, you're not going to be working with the project architect as an equal. You're going to be working for them, doing the things they've decided, doing them mainly in the way they want them done and under their direction.

However, you must recognise that the person you are working for is also working for you. Your relationship is a reciprocal one and provides you with an opportunity to shape things for your purposes. It puts some equality back into the relationship because if the project architect wants you to do something well, they must brief and guide you.

You are working for them, but they are working for you.

Delegation, but from your point of view

Giving a task or responsibility to someone else is usually known as 'delegation'.

If you refer to books on the subject of delegation or search for articles online, you'll find a vast amount of material available. The problem is that it tends to be written for the person doing the delegating and not for the person doing the task or picking up the responsibility. The result is that delegation often sounds like a thing that is 'done' to you as if you were the passive recipient of something, whether you like it or not.

In these posts, I'd like to change the perspective and illustrate what delegation looks like for you. The word 'delegation' isn’t great, and I would prefer one emphasising the arrangement's two-way nature. A word that would make it apparent that as well as doing the task, you also have a responsibility to make the process work just as much as the person giving you the task.

The other problem with the literature on delegation is that it often remains impersonal, with the protagonists awkwardly labelled the 'delegator' and the 'delegatee'. To make things more realistic, I will refer to the person doing the delegating as the 'project architect' (although it could be anyone) and the person doing the task as 'you'.

Even a simple task can become complicated

Here’s an example of the delegation of a simple task.

The project architect says to you:

“I’ve marked up a print of a drawing with some comments and amendments. Can you update the CAD file, please?”

Response scenario 1:

You do it. It takes 2 hours, and you’re ready for your next task.

Response scenario 2:

It takes all day (8 hours), and you’re not sure about a few things. That's four times longer, and some elements may be incomplete or not quite right.

Here are some things that might have slowed you down:

Project Architect

• They were very busy and didn’t have time to explain everything.

• They weren’t available to answer questions.

• They didn’t state how long the task should take.

Aspects of the task

• The notes on the drawing were illegible.

• The computer file was a mess and needed sorting.

• There were other distractions (phone, CPD, a birthday celebration etc).

You

• You didn’t ask any questions.

• You weren’t fully familiar with the CAD software.

• The drawing needed a formal revision, and you didn’t know how to do this.

As you can see, numerous things could turn what you both considered a simple task into something much more protracted. So, what can you do to help steer the work towards a more successful conclusion?

Dealing with the complexity of the situation

A detailed answer will depend on the particular circumstances of the task, but I can outline some general principles.

1. When you receive the task

Listen carefully and try to understand what is required. Ask questions to make sure that you've got everything. Take notes. Repeat the task to the project architect to ensure you've got it right. Ask for any missing information that occurs to you, for instance:

• How long does the project architect expect the task to take?

• Will they be available to answer questions?

• What do they want you to do with the work when completed?

Aside from understanding the task, this is mainly about you managing the project architect. As the person doing the work, you have a different perspective and can usefully help to fill any gaps in the briefing.

2. Before you start the task

Having read the comments and looked through the CAD files, go back with any issues before you start, such as:

• Anything that was illegible or that you didn't understand.

• Anything that arises, having understood the implications of the task.

• Your opinion as to how long the task might take.

Ensure that you're starting from the right place and that you and the project architect share the same expectations for the task.

3. While you’re doing the task

Problems may come up that neither you nor the project architect expected, leading to one of three scenarios:

• The issue is small and surmountable, in which case you can resolve it yourself.

• The issue is surmountable but will cause the task to take longer, which should be discussed with the project architect. The project architect will then be able to participate in any time vs quality decisions, which will help manage expectations about how long the task takes.

• The issue is not surmountable by you, which should be discussed with the project architect. The project architect will then be able to decide what to do about it, which could mean arranging for help to resolve the issue or providing training for you so that you can do it yourself.

Ensure that you and the project architect share the same expectations for the task as things arise.

4. When you’ve completed the task

You were doing the task for a reason, and ensuring you have accomplished the objective will be essential. Ask the project architect for confirmation that the work has been done correctly and ask questions, such as:

• Do they want to check the work?

• Who else should you inform as a result of completing the task?

• Does anything else need to be done before moving on?

Ensure you have completed the task satisfactorily and implemented the correct follow-on actions.

Your goal isn't just to get the task done. Three things must look good: the work itself, and you and the project architect. You have a role in managing things to make sure that this happens.

Self-direction vs working in a team

Previously I emphasised that delegation is a two-way street, that things are interrelated, and that, as the person doing the work, you need to participate in managing the whole process.

However, it is also possible that you are doing your work within the context of a wider team, and this has the potential to bring on more complexity.

If that wasn't enough, there is also the fact that most of us want to be left alone to get on with our work! We take satisfaction from being given a new challenge and successfully overcoming it. When we can do the work, it is tempting to, metaphorically, 'take it away' and only 'come back' when it’s done.

Our preference for self-directed work is borne out if you look into motivation. Author Dan Pink*, in his book 'Drive: The surprising truth about what motivates us', concludes that once we’re satisfied with the money we're earning, the things that motivate us are mastery, purpose and autonomy.

Your mastery and purpose motivators are inherently present because of your desire to become a good architect. However, the idea of being able to work autonomously may seem a long way off for now, given that you're dependent on other people to guide you.

You will always be working as part of a team, and you will never be a completely autonomous worker. Even when experienced, you will need to keep 'checking in' with other team members to ensure that your work continues to co-ordinate with what everyone else is doing.

You need to develop a mature view of your role. At times, take responsibility for what you're doing and get your head down to do it; at other times, look up to obtain a broader view and take responsibility for the team.

But, for now, that is just something of which to be aware. In the early days, you can generally rely on the project architect to think on behalf of the team while you focus on the task at hand.

Note*: You can find a graphic summary of Dan Pink’s work here.

Summary

I've used an example of a simple task to demonstrate that your role is more involved than just doing the work. It also requires you to participate in managing the delegation process to ensure the best possible outcome, especially when unforeseen issues come up.

In addition to doing the work, your main objective is to ensure that you and the project architect share the same expectations.

This means that you shouldn’t be afraid to:

• Ask questions.
• Say you don’t know how to do something.
• Go back when something unexpected comes up.

And that you should:

• Help the project architect to give a complete brief.
• Monitor your progress against expectations.
• Make sure the task is complete.

In Part 2 of this post, I'll look in more depth at what happens on more complicated tasks when you have the experience and skills to do the work independently.