Technical lead as mentor
A new project presents a problem, but also an opportunity to train and advance your people.
Consider this scenario playing out at a manufacturer, equipment supplier, or system integrator: an engineer with good technical experience is assigned as technical lead on a new automation project, but then is faced with a critical decision. Should he or she organize the project the usual way, with the same roles for each person in the same type of group as the last project, or shake things up a little and consider it an opportunity to improve the skills of the people involved by mentoring them and making them stretch their abilities?
With the old way everyone’s responsibility is well defined, but it leads to the familiar question, do you (or they) have ten years’ experience, or one year’s experience ten times? Doing the same things over and over again does not give people, including the tech lead, the opportunity to grow. What if this is the engineer’s first time as a tech lead? What is the best approach, and has the engineer received mentorship on that new role? This discussion will examine the definition of mentoring in an industrial context and what benefits it can have, with a guide to carrying it out.
Any mentoring effort rests on a number of assumptions, some stated and some only implied:
- Management understands the benefits of team development—No development strategy will work if management is not on board and willing to invest the additional time for all involved. The team members must be permitted the flexibility to invest in their own advancement.
- The tech lead is motivated to develop the team—If the tech lead does not see the benefit of being a mentor, the mentoring program cannot succeed.
- The team members want to be developed—Each team member has different life and career goals, and it is ineffective to try to teach someone who has no motivation to learn the subject or advance in an assigned role.
- The tech lead has some interpersonal skills—A teacher is defined by the ability to teach, not the capacity to know. Mentoring cannot succeed if the mentor is unable to communicate his or her experience. It is also worth considering that teaching a subject may be one of the best ways to understand it fully.
Tech lead responsibilities
In the past, the tech lead was responsible primarily for technical matters. This role is expanding, encouraging the tech lead to understand politics, relationships, and accounting in order to facilitate or replace project management. Technical leads are now accountable to both their management and the end user. They are responsible for orchestrating the project team, executing the project, and resolving project issues. They must also report progress to management and end users, provide technical commentary on requirements, and keep the schedule and budget under control. In the end, the job can often be boiled down to creatively doing what can be done with the resources that are available.
What is a mentor?
A mentor’s job is to advance the professional development of someone else, often—but not always—in an informal situation, and to create an environment that encourages openness and builds confidence. This requires social competency on the part of the mentor, and unfortunately, there are still some technical experts who seem to pride themselves on their lack of people skills. It is vital to drive out that mentality. Having a mentor who is willing to teach is as important as having someone who wants to learn.
Mentoring does not have to follow a set schedule, but it is important to pursue it proactively. It can be spending an extra five minutes with someone, rather than simply telling him or her what work needs to be done and walking away. It means taking the time to think about what the mentees are actually doing, where their careers are going, what information might help, and what other things they might care about—in short, getting to know and care about the people as individuals.
The mentor is responsible for the development and advancement of individuals, but must also maintain confidentiality and behave in an ethical manner. The mentor is accountable both to him or herself and to the protégé, which translates to one who is protected. If the protégé cannot trust the mentor, the effort is futile.
Mentoring and coaching have much in common, but the former tends to be more focused on the development of an individual, while coaching is directed more towards improving the performance of a team. The coach archetype is generally seen as an authoritative figure. Conversely, a mentor is generally a peer, partner, or friend.
A coach is accountable to the team, and is responsible for setting team objectives, driving their realization, maintaining team engagement, inspiring, and motivating the team.
For an organization, instituting a mentoring program can present challenges in training and in the resetting of organizational climate, but can boost employee satisfaction and in turn improve core competency retention.
On the training front it is vital to plan ahead for the fact that it is usually difficult or impossible to hire people who can simply step into a position. This is particularly true in the automation field, as few academic programs exist for this career path. It may be possible to poach people from another company in the same industry, but unless they come from a direct competitor they will still require considerable training: not all the skills learned in, say, the power field will be directly applicable in the wet sciences. Fresh college graduates will most likely not be fully productive for some time after being hired, unless they have had the opportunity to participate in focused internships.
Taking on a mentoring role is a good way for a technical lead to shift to the management track and open new horizons, but remember the old saying, “if you can’t be replaced, you can’t be promoted.” A mentor must develop a succession plan and groom a replacement. Succession planning is taught in business school, but few engineering schools pay attention to it.
Of course, none of this means very much if the organization has not defined engineering career tracks. In some companies, technical leaders may not all want to move into management. Some are satisfied with their positions and enjoy mentoring others and helping mentees move past them if they want to. In this climate, the upward-looking tech lead has the choice of becoming an exception, trying to change the culture, or looking for another company with a different culture.
Colleges tend to do a poor job of preparing young engineers for the messiness of actual projects. Some projects gradually grow to encompass more and more, which we term scope creep. Some are vaguely defined—having too little or even no definition, which leaves the engineer with little guidance on what’s really wanted. Others are so over-defined that there’s no opportunity to adjust to changes as they appear.
Some projects are done in a rush, with no chance to get the people involved fully up to speed. The tech lead has to worry about making sure enough people are available, motivating them, making sure they have the necessary skills, and integrating everyone into a smoothly functioning team. There are two ways to learn how to deal with challenges like these: either suffer with them for several years or be guided through them for one year by someone who has been there before.
New tech lead challenges
A new tech lead faces other challenges in addition to those traditionally assigned. An engineer is commonly promoted to a lead role in recognition of demonstrated technical proficiency and leadership potential. He or she is typically respected for having “been there” by other team members and for understanding what it takes to get the job done. But such a person may well have little to no leadership or management experience, and must learn project management, leadership, and client relationship skills on the job.
It is a fortunate engineer who, while gaining the five or six years of engineering experience that culminate in being a tech lead, has his or her own mentor who will suggest delegating some work to three or four co-ops or interns, being in charge of them, and taking responsibility that they get the job done. Similarly, an engineer’s development will be aided by participating in meetings with clients, and learning the dynamics of project execution and management. Sitting in a closet and writing code will not develop these critical skills.
Once in the role of tech lead there is the question of whether to remain there. Projects start to all look the same if you do the same role every time. Each project may have its own challenges, but after 15 such projects very little seems new. While some people are content in such a situation, others are looking for the upward or more challenging path, but do not want to abandon the technical aspects for pure management.
Fortunately, organizations tend to value middle management with strong technical skills. One might step into the role of a staff consultant, for example, being essentially a full-time engineering mentor. There are other paths, but it is important to think about all of the alternatives before committing your career development to one.
Plan, execute, repeat
For a person who was never a team captain in high school sports or president of a campus organization, a leadership role can be new, unfamiliar, and stressful. Leadership ability grows with experience and quiet contemplation. Every project allows the tech lead to develop a leadership style, and become more comfortable in a leadership role, but this process is often unguided. When the inevitable questions or challenges arise, when someone says, “well, that’s ridiculous, you shouldn’t do that,” it is beneficial to look back at experiences with a mentor who taught the ability to have confidence in one’s own management style.
With more experience, there is a temptation and tendency to fall back on tried-and-true methods, to do the same things each time. This will almost guarantee that each project will give the same results, and will provide protection against unexpected discomfort. Yet this can be a trap, because it means an end to learning. It prevents unexpected stress, which prevents the learning that comes with unforeseen circumstances. This is important to remember not only for one’s own development, but for mentoring others as well.
Good intentions vs. reality
Good intentions are plentiful: “Let’s get everybody trained. Let’s make everybody tech leads.” Unfortunately, often things do not work out that way, as can be seen from the small number of senior- or principal-level engineers who have moved into the upper ranks of corporate hierarchies.
Tech leads have good intentions of their own. But while a tech lead may want to make the team members better at what they do, he or she needs to make the project succeed, which leads to the tendency to assign tasks to people who can already do them. But it is critical to stretch the people on the team to do new tasks. It is unwise to give individuals assignments that are five years past what they
can do. That loses an opportunity to stretch them a bit, to give them incremental steps so that in the end they realize they can do much more than they could before.
Young people fresh out of college are in greater need of guidance, because they don’t know what questions to ask. The tech lead should not just lecture them on what they need to do, but should guide them to which questions they need to ask, because it is possible that on their next project they will not be working with a tech lead who is as focused on their development.
Experience from other industries
While the industrial automation business has been doing the sorts of computer science heavy projects it does today for perhaps five or 10 years, the software development sector has been doing them since the early ‘80s and has developed many useful methods. It is worthwhile to look into some of these, including the waterfall, “V”, and Sashimi models for project management methods, as well as the more recent Agile and eXtreme Programming software development models.
The business development world has much to teach automation professionals as well, particularly in areas such as formalized succession planning. Professional educators have much to teach about personality models and learning styles. Remember that everyone learns differently, and teaching everybody the same way generally means that you’re actually teaching only the weakest individual in the group.
Skilled trades, such as electricians and plumbers, have had apprenticeship programs for hundreds of years. A number of countries have formalized such apprenticeship programs, with Germany’s engineering apprenticeships as the best-known example. Pakistan uses apprenticeships to train its IT professionals. A number of well-regarded universities in the U.S. have cooperative education programs where students spend half their time in class and half in actual jobs in industry. They often emerge more ready to succeed than they would be if they had stepped directly from the classroom into industry.
Benefits of mentoring
Mentoring has benefits for the tech lead besides those mentioned previously. It adds another point of contact for involvement with the actual work being done by the team, and thus can enhance reporting up the line and help a project go more smoothly. It gives the tech lead a stronger understanding of the team and of team members’ individual competencies heading into the next project. At the end of the project, when a manager says, “give me a rundown on what everybody did and where we can use them in the future,” the tech lead will have a real answer, as opposed to just saying, “work X from engineer Y came out without any errors, so he or she is good at that task.”
Mentoring keeps team members more engaged and opens a line of two-way communication for real feedback. A team member who is being mentored is less likely to be afraid to give a truthful opinion to his or her tech lead.
Potential + motivation + availability = development
A mentor must make certain assumptions at the outset: that all people have some kind of potential, and that all people have some kind of motivation. It is also important to realize that all people have real limits on their availability. A mentor can learn what all these things are only by developing relationships with the team members individually in order to find the best way to help them excel.
Quality by education
Quality guru J. M. Juran is credited with the concept of quality by design (QbD). Juran believed that quality could be planned, and that most quality crises and problems relate to the way in which quality was planned in the first place. Similarly, in order to design something it is necessary to be educated about it, which leads to the new term quality by education. This concept says the most important design tools are education and experience. The mentor must translate and transfer his or her experience into the team members’ education.
Words of advice
There are many suggestions for practical ways the tech leader can start down a more proactively developmental path. Here are a few:
- Have your team members provide a peer review of your work and the team’s work;
- Expose your team members to their clients;
- Explain the big picture, but let the team members come up with the details (supervised autonomy);
- Assign teaching tasks (delegate leadership);
- Promote critical thinking, not just output;
- Know your team members’ preferred learning styles;
- Involve your team members in the big decisions that affect them;
- Have your team members supply the justifications for changes (budget, schedule, hours);
- Explain business decisions;
- Make your team members accountable but protected;
- Know their individual career goals;
- Support those goals with appropriate assignments;
- Be involved with your team’s work; and
- Guide before driving.
Quantify individual development
With mentoring or any goal-directed activity, it is essential to have some way to measure progress. This means developing a set of targets: specific skills that individuals develop over their careers with an automation company, including technical implementation skills, technical design skills, and communication skills (to groups, peers, clients, and managers). A useful method is to generate a matrix of when people should have specific skills and then use that matrix to challenge them to do things that they haven’t checked off their lists yet. It is not enough simply to assume or demand a person has the needed knowledge or skills without having made a clear statement of what those skills are.
Mentoring has benefits for both the mentor and mentees, and for the organization as well. A mentoring program helps to increase the core level of competency in the company, which helps ensure better work and better end results. Having a good mentoring program helps the company retain the people being trained, because it gets them more involved and there’s more in it for them than just their salaries. Finally, knowledge of the company’s commitment to educating people helps make clients more comfortable and delivers greater return on investment.
With some planning ahead, it is easy to develop the team while developing the project. Doing so will make the job of the tech lead easier by delegating existing experience to the team, will enhance the capabilities of the organization, and will make the overall end product more integrated, intelligent, and robust.
Terry Seanard is senior systems engineer for New England Controls in Mansfield, MA.
For more information, visit:
|Search the online Automation Integrator Guide|
Case Study Database
Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.