Chapter 12
In the last three chapters, I introduced the idea that engineering knowledge and resources are accessed through other people; that things happen in engineering through a social network. In this chapter, I explain how engineers make things happen when needed.
We learned about different kinds of knowledge in Chapter 10 and how acquiring knowledge is slow and susceptible to misunderstandings. Therefore, it is much faster and easier to arrange for people to collaborate and perform work that requires their specialised knowledge, skills, and resources rather than trying to learn for yourself. However, persuading busy people to do that, to make things happen when you need them is not easy.
The least effective way to ask a person to do something for you is by email or text message. There is a very good chance that nothing will happen. If something does happen, it’s probably the wrong thing.
Most people in an engineering enterprise are working on many different tasks, more or less simultaneously. As a novice with perhaps two or three emails in your inbox each morning, you need to appreciate that people you need help from may have 50 or 60 issues vying for their attention, and hundreds, even thousands of unread emails. An email from you asking for information or help hardly registers at the bottom of their priority list and may even be forgotten in a few hours as it slips off the bottom of their inbox screen to join thousands of other unread emails.
Another way is to ask your supervisor to ask his or her supervisor to get the ultimate supervisor of the person who you need to do something to direct that person through their chain of supervisors. In other words, exercising management authority, working through an established organisation hierarchy that seems to exercise command and control throughout the organisation.
Think again.
First, it is very unlikely that the necessary messages are read, and perfectly understood by everyone up and down the hierarchy. Second, almost certainly you will be waiting a long time for anything to happen. Quite possibly, the wrong person will end up coming to do the work, and you will find that you need to ask all over again. In the vast majority of cases, you can persuade the person you need to collaborate with much faster on your own.
But how, you ask, can I, the most junior and inexperienced person in the organisation, possibly just walk up to someone and ask them to do something for me? Especially when they know far more than I do. I hardly know enough to ask them what needs to happen.
In answer to those questions, this chapter explains technical coordination, a special kind of informal leadership (Professional Engineering Capability Framework, Sections 2, 13):
Technical coordination, arranging for people to help you make things happen, preoccupies almost all engineers every day, from the first days of their careers, mostly without them ever thinking about it. It is the main method that engineers use to access technical information when they need it. Most often, when facing project deadlines, it is faster and easier to find someone with the knowledge, skills, experience, and resources to make a contribution quickly and skilfully. The right person may also have access to resources such as technical information, special tools, and equipment; through their networks, other people who you might not even know are needed to help.
Technical coordination seems to be something that all engineers do and takes around 30% of their work time. Even though some aspects resemble project management, at least in principle, they are distinctly different performances. Project management is a formal process that relies on documents and formalised relationships that we will discuss in another chapter. Technical coordination is an informal process that relies largely on undocumented social interactions and informal messaging.
I describe it as a four-step process, explained below, in which you gain the willing and conscientious collaboration of another person, which we refer to as a ‘peer’. It does not depend on organisational authority or management hierarchy. In fact, conscientious collaboration is often more likely to occur in the absence of authority. People collaborate out of respect for one another.
Developing the capability for effective technical coordination is probably the single most effective way to build your engineering career, and emotional intelligence is an important attribute that helps. Employers value the ability to ‘get things done’ extremely highly (Figure 12.1).
Figure 12.1 Four-step technical coordination process: ‘peer’ refers to the person (or people) being coordinated.
Step 1: finding a peer
You will often know who is the best person to help you. It could be arranging for a specialist component supplier to provide samples for testing or evaluation. You could be coordinating work at a construction site, arranging to collect concrete samples for testing, and checking the installation of formwork for the next concrete pour. You may be coordinating the work of a maintenance contractor installing software upgrades at a telecommunications centre.
At other times, you may need to ask other people to suggest someone who has some specialised knowledge—for example, about different kinds of explosives. It helps to visualize a social network of technical expertise, as illustrated in Figure 12.2.
Figure 12.2 A social network of expertise. Thick lines represent strong, collaborative relationships.
You, the novice, are the centre, and you now know a couple of people well, perhaps your supervisor and one colleague. Thick lines denote strong relationships, while thin ones represent weaker ones.
Start by reaching out to knowledgeable and experienced people with whom you already have strong relationships and ask them to refer you to others who have the expertise you need. If they were unavailable when you visited or phoned them, do not send text messages or emails unless there is no other way to reach them. If you do have to reach out by email, ask for another time to meet or call:
I visited your office and tried to call you today, but you were not available. Please suggest a time that I could come and see you or call by phone.
They may suggest a phone call. That can work, but face-to-face encounters are much more effective, as explained in Chapter 7. If they can’t help, ask them to suggest others who might be able to assist. Especially as a new person in the organisation, it is usually much better to meet people face to face for the first time.
It helps to continue building relationships with all the people you encounter in the search, as explained in Chapter 9. People with whom you have an existing relationship are far more likely to help you.
Step 2: discovery, organisation
The absence of authority requires that you agree with the peer on what they are expected to do and when. Even before this takes place, you should discuss current commitments with the peer and also consider the peer’s know-how, values, and interests. This involves mutual discovery, preferably through a face-to-face discussion, so that you can confirm that the peer is the right person, and he or she will have enough time to complete the request on schedule.
It may be necessary to negotiate your peer’s availability at certain times. He or she may need to renegotiate existing commitments and rearrange their schedule for the new task.
Unless the task is very short, it’s a good idea for you or the peer to seek approval from, and at least inform, both your and the peer’s supervisors, and also possibly the managers of any project teams to which they are currently contributing. There may be cost and budget implications. Apart from the cost of the time contributed by the peer, you will also need to spend time negotiating and monitoring the work as it is done.
Having cleared the way for the peer to devote time to the task, the next step is agreement on the details of the task between you and the peer. Again this is a mutual discovery performance because you will probably not know enough to be able to completely define the task without discussing it with the peer. The peer usually has special resources such as technical knowledge, skills, facilities, tools, or access to equipment—this is the reason why you need the peer to perform the task. You need to learn from the peer at the same time as the peer learns about the requirements from you. Together, you jointly ‘firm up’ or ‘discover’ the requirements as you improve your respective understanding of one another; gradually eliminating mutual ambiguity and negotiating the meaning of words you both use to define the task. It takes time to develop confidence from listening to the peer that the requirements are sufficiently well understood for them to start work.
If the task is complex, you may jointly develop a written work breakdown structure. In the case of a contractual arrangement, this kind of documentation is probably essential and may need external approval.
The last step in the organisation stage is to agree on a schedule, not only for the task completion but also for monitoring. You will monitor the task more or less frequently as the work progresses.
At the same time, at least privately, you need to anticipate issues that may arise during the task performance and assess risks that could affect the task performance schedule or quality. You should try to foresee unpredictable events and have some idea of how to handle these events if they occur, in conjunction with a series of backup plans. Of course, if there are health and safety issues, then it is essential to discuss these with the peer as well, and possibly others.
Step 3: monitoring—another discovery performance
Monitoring the task, often called following up, can be the most time-consuming step. It is a repetitive process, but it is also essential. Without monitoring, the peer may completely forget, or the work may be delayed because the peer focuses on other priorities. Another reason for monitoring is that you still carry responsibility for efficacy and safety. The peer may not have sufficient understanding to appreciate the potential consequences of the task, so monitoring and supervision are essential to ensure that intentions are enacted appropriately (Figure 12.3).
Figure 12.3 Monitoring process for technical coordination. Once the peer signals that the task has been completed, the final step—completion and handover—will begin.
Monitoring starts with a prediction: the coordinator anticipates the current task status and progress, usually quite informally. Technical knowledge and prior experience help a coordinator make more accurate predictions, as they will know what to look for while following up.
The coordinator arranges to meet the peer face to face or at least to discuss the task by telephone. Monitoring by email is a last resort and is unlikely to be an effective way to rectify performance issues. The ‘inspect progress’ block in the diagram represents another discovery performance: a discussion with the peer about the task that results in the coordinator learning how the task is progressing. In doing so, both may also discover misunderstandings about the requirements and adjust their expectations accordingly.
Having assessed the actual state of the task, the coordinator then reflects on the difference between the predicted and actual state and, in doing so, adjusts expectations for future progress prediction.
The coordinator thinks ahead and anticipates consequences. For example, there may have been a misunderstanding about the requirement for quality; the peer may be taking much more time than was originally foreseen, ensuring that the work is performed to the highest standards through extensive checking. The coordinator may not have clarified the expected quality standard for the work. Also, engineers prefer to take time to seek the best possible results and check their work carefully. In the early phases of the project, particularly if the coordinator needs only a rough estimate from the peer, there may have been the expectation for the work to be done quickly.
The coordinator may have to think about different kinds of consequences and risks. If the task is being performed on a budget, he may have to renegotiate the budget or make allowances elsewhere. If the completion time is important, the coordinator may have to change the scope of the work or even find someone else to help move the process along.
If there has to be a change in plans, it takes time to discuss this with the peer, revise the current plans, and then implement changes. Bringing someone else in to help might sound like a good idea, but it almost invariably requires a significant amount of time; the two peers may also take more time to establish a productive working arrangement on the task. There is almost always some delay as a result of changing plans.
Mostly, this is all an informal process—monitoring hardly ever involves any documentation or notes.
The most important decision for the coordinator is to decide the frequency of monitoring. Too much monitoring can undermine trust—the essence of coordination is willing collaboration, and the coordinator has to display that confidence to the peer.
If the monitoring is too infrequent, however, then issues can arise that may seem unimportant to the peer but may be very important for the coordinator.
Another kind of issue is a technical difficulty that the peer feels confident in solving and continues to work through, relying on that confidence. The peer may try several different solutions before asking for help or even alerting the coordinator that there is a problem. The peer may need assistance from someone else, but that person may fail to respond as expected. The result is an unexpected delay.
As a rough guide, therefore, monitoring frequency depends on the likelihood of an unexpected issue occurring that the peer cannot solve by themselves, and the ‘float time’, which is the allowance in the schedule for unexpected delays. You should also take into account the possibility that if the peer cannot solve the problem, then it may be even more difficult for you to solve it; you may have to seek help from someone else.
Consider the supervision of a maintenance crew inspecting and replacing seals at bolted joints in a high-pressure gas pipeline. Technicians dismantle the joints by loosening and removing the bolts so that the internal seals can be inspected or replaced. Then, the technicians replace the bolts and tighten them using a torque wrench to ensure correct tension.
How do you ensure that the bolts are correctly tensioned? Or, as an electronics engineer, how can you tell that some delicate components have been appropriately handled in a clean room and protected from static discharge?
One option is to watch each technician, telling them not to proceed to the next stage until you have checked. This would be extremely time-consuming. It would be impractical to supervise more than two technicians working in the same location.
Instead, you would more likely allow the technicians to perform their job, knowing that they probably have far more experience performing this kind of work than you do.
Returning to the pipeline maintenance scenario, how can you tell that the bolt has been tensioned correctly? There is no difference in appearance. Perhaps you could use your own torque wrench to check the tightness of one or two of the bolts. However, you would not be able to tell whether the bolts had been overtightened, and then loosened, and then tightened to the correct setting. Would this matter? Yes, it would. Particularly in a high-pressure pipeline, ensuring that the bolts are correctly tensioned and not overtightened is essential to avoid fatigue damage to the bolts, as they are subjected to very high stresses in normal operation. Overtightening can permanently damage a bolt, causing invisible elongation, damage to the threads, and even a slight, but significant, enlargement of microscopic cracks in the metal.
Therefore, even though you are responsible for the repairs being performed correctly, you cannot actually observe every technician performing their work. Instead, you have to rely on the willing and conscientious collaboration of the technicians. You are relying on their willingness to perform the work correctly and conscientiously, taking care to ensure that their work is done correctly.
What we can see here is that the technical quality of the work performance affects the results in a way that may not be visible, even to someone watching at the time. As we have seen before, most engineering is performed under strict time and budget constraints: the work has to be completed according to an agreed-upon schedule and cost. Therefore, a great deal of technical work relies on both the conscientious performance of the work by individuals taking care to make sure that there are no mistakes and the levels of delegation and checking to minimise the likelihood of mistakes.
Trust makes a large difference here. Peers whom you trust require much less monitoring than people with whom you have not yet developed a trusting relationship. Trust translates into large time savings, reducing costs for everyone.
Contriving casual encounters
Naturally, most people are uncomfortable with excessive monitoring. Frequent monitoring can undermine trust and confidence. However, frequent monitoring is often the only way to keep a task on track, especially when the peer has numerous other distracting priorities to work on.
You will get to know that some people, even ones in whom you have the highest trust, will need frequent reminders, often the briefest phone call, just to keep the memory of your work sufficiently prominent in their minds.
Often, the monitoring only serves to keep you, the coordinator, in the mind of the peer, so they don’t forget about the task they are performing for you. It is possible to do this in other ways, by contriving casual encounters.
An engineer described this technique:
When I need to coordinate some extremely busy people, I try and position myself with a view of the corridor that leads to the bathroom or the coffee machine, preferably both. Then, when I spot someone who is likely to run late, I’ll arrange to show up at the coffee machine or bathroom at the same time, seemingly by coincidence. Often, I will make sure I talk to someone else: all that is usually needed is for the other person to notice me and that makes them remember they’re running late.
Step 4: completion and handover
The last phase in technical coordination involves careful checking by you and the peer to ensure that everything has been completed to their satisfaction. It may take time: you may both agree on testing with the expectation that any remaining performance issues identified as a result of testing will be rectified later (Figure 12.4).
Figure 12.4 Completion and handover phase. The coordinator has to evaluate the consequences of any deviations from the agreed-upon task scope, as well as the cost and risks. If necessary, the coordinator will insist on deviations being rectified, accepting that there will be a delay and another inspection.
It is a good idea to avoid a premature declaration that a given task is complete. Remembering that technical coordination relies on willing collaboration, it can be embarrassing to go back to a peer and confess that you did not check the work thoroughly enough when you initially accepted it. However, this can sometimes happen, even with the best intentions.
As with monitoring, your technical knowledge is essential to predict the consequences of accepting any remaining deviations, including the ultimate risks of doing so.
The most important aspect of the completion phase is to remember that task completion is not the only valuable outcome. As the coordinator, you and the peer will have strengthened your relationship. Relationships endure much longer than temporary coordination arrangements. Therefore, it is important to maintain that relationship. Otherwise, you will risk giving that person the impression that the relationship was only important in order to get a particular task completed.
This does not mean that you need to spend an excessive amount of time with the peer. However, it also does not mean that you can completely ignore the other person indefinitely or until the next time you require their collaboration. Take the time to visit the peer occasionally and view this as an important aspect of your work: building and maintaining trusting relationships.
Informal leadership, face to face
Technical coordination can also be seen as informal leadership. Most novice engineers, and many experienced engineers, reject the idea that they are exercising leadership.
Remember, as an engineer, you only achieve something by influencing the way that other people perform their work: manufacturing or assembling products, operating systems or processes, or delivering services to end-users. Influencing the way that others perform their work is a form of leadership. Influencing skills, therefore, are essential for engineers.
As we have seen in this chapter, successful influencing relies extensively on listening and perception skills. Go back to Chapters 4–8 regularly to evaluate your perception skills.
Face-to-face interaction with another person is nearly always the best way to start, but sometimes a carefully prepared piece of writing can convey ideas far better than a conversation where, perhaps, the other person is only half-listening and has several other pressing matters vying for attention. If so, use the conversation to alert the other person that you will send your ideas by email in writing, and then when they have read the email, you could meet to discuss them.
Social culture
Social culture can impose many complex constraints that can affect technical coordination. In many low-income countries, for example, it is well known that productive work requires the continuous presence of supervisors. Work quickly stops whenever the supervisor is absent, as explained in Chapter 17. Following up by telephone in South Asia, for example, can require phone calls several times a day.
In North American cultures, exercising influence without authority can be more transactional than in other countries. The peer may see the work as a kind of favour, to be repaid at some time in the future. In other cultures, the motivation comes more from mutual respect between the coordinator and the peer and the strength of their pre-existing relationship.
Practice exercise—knowledge network mapping
Map the knowledge network in your enterprise, at least within the circle of people that you routinely encounter. Remember that some of the people in your network, possibly many of them, work for other organisations, or maybe clients or end-users. Make a photocopy of Figures 11.5 and 11.6, and try to write names on each cloud to indicate people with the respective knowledge category. Draw lines of different thicknesses to indicate the strength of relationships. Repeat this after several months—you may be surprised to see how much it changes.
References and Further Reading
Blandin, B. (2012). The competence of an engineer and how it is built through an apprenticeship program: A tentative model. International Journal of Engineering Education, 28(1), 57–71. doi:0949-149X/91
Kendrick, T. (2006). Results without Authority: Controlling a Project When the Team doesn’t Report to You. New York: AMACOM Books: American Management Association.
Rottmann, C., Sacks, R., & Reeve, D. (2015). Engineering leadership: Grounding leadership theory in engineers’ professional identities. Leadership, 11(3), 351–373. doi:10.1177/1742715014543581
Trevelyan, J. P. (2014). The Making of an Expert Engineer. London: CRC Press/Balkema - Taylor & Francis, Chapter 9.