This is the latest entry in an occasional series on followership. The premise, as stated here, is that not everyone gets to be a leader, and most leaders are also followers in their own right. The project manager follows instructions from the project sponsor, the CEO from the board, the politicians from the polls, and so on. Whoever you are, you spend a lot more time following than leading. As Bob Dylan put it so well, “you gotta serve somebody.”

The good follower is not a “yes man“. In the professional world I inhabit those who move “up” the hierarchy tend to retire technical skills in favor of architecture, proposal writing, and management. The relationship of manager to employee becomes more like agent to actor or musician, where the supervised employee is the “talent”.

In these conditions the old concept of top-down decision making seems quaint. Important choices require information from all perspectives, and organizations shut out those with knowledge of the details at their peril. The best decision makers search out diverse ideas before choosing a direction.

However, that’s not always the case. The busy manager racing to keep up with a heavy workload might resent unsolicited input as a distraction. The employee or consultant tasked with a specific responsibility might shy away from providing insights, however valuable, outside their “job description”.

But sometimes a good follower should advise his or her leader. Leaving aside situations involving illegal or unethical behaviors, there are often cases where a team member observes suboptimal situations, plans, or behaviors and wants to help. How that advice is offered can make the difference between resistance and improvement on the part of the manager. Here’s a process to help ensure the latter:

1. Get your facts straight

Let’s use this situation as our example: you’re a .Net developer on an application development project. The data modeler resigned shortly after completing database design, and the system architect, a close friend of the erstwhile modeler, is maintaining it off the side of his desk as application development begins in earnest. You have a background in data modeling. Having reviewed the database design you have grave concerns about how the system will perform with such a poorly designed database. The team is a quiet group and all have great respect for the architect, a noted local app dev expert.

In this situation you should speak up to the architect about the risks imposed by the subpar model, but not before you do your homework. Start by grounding your gut feelings. In this case:

• What are the specific problems with the database design?
• Did the original modeler apply an appropriate technique that you just don’t know about, like name-value pairs or dimensional modeling?
• Can you demonstrate that queries to be used in production will be slow?
• …and so on.

2. See things from the manager’s perspective

Once you have your facts straight, the next step is to take a walk in the architect’s moccasins. Spend some time thinking about what the architect does all day, his or her interests, what he or she delegates versus personally taking on. You’ll gain insight on how to effectively express your thoughts, and you’ll adjust your presentation accordingly as you reframe from a larger perspective.

3. Scrub out negative emotions

If you’ve been thinking about the problem for a while you may find yourself worked up with frustration and resentment. Hopefully thinking about things from the architect’s point of view has taken the edge off, but if not it’s time to cool it. A passionate presentation of your views will make them more compelling, but any resentment or frustration added will render your enthusiasm abrasive. The meeting will only succeed if both parties look forward to repeating it.

4. Advise in person and in private

You might document your thoughts, but don’t be tempted to send them by email and be done with it. Unless very carefully crafted, written feedback comes across as more blunt and uncompromising than intended. And it is irrevocable – don’t risk clicking send and then regretting something you’ve written.

Find a way to review your concerns one-on-one in private. Your goal is a collegial free exchange of ideas in which your concerns are fully aired. Expect the architect to offer thoughts and ideas that you hadn’t considered. Best case you’ll both emerge with deeper understanding of the problem and a plan that neither of you could have foreseen.

In order to set up that sort of dialog, start by expressing your commitment to success of the project and desire to help. Here’s a good first two lines: “I want to do everything that I can to help make the project succeed. I’ve noticed something I wanted to bring to your attention, would it be ok if we compared notes?”

5. Help make a plan

It is rarely a good idea to call out a problem without also offering a solution. If you put yourself in the architect’s place, the last thing you would want is for someone to dump yet another problem in your lap.

Think through how you might solve the problem while still keeping the project afloat. If the problem focuses on certain areas of the data design, then can development begin on unaffected areas while data design is corrected? Can a data access layer be added to the application so programming can continue unaffected by data model changes?

If you bring solution ideas to the table then the architect will see you as a helpful collaborator. Otherwise, the conversation may start well but fizzle out with the architect saying “you may be right but its too late to fix the data model now that development has started”.

—

Don’t be fooled by the hierarchy, in today’s world everyone on the team is responsible for success of a project. An effective team member understands that one element of good followership is to criticize well. If you have your facts straight, understand the leader’s perspective, remove your negative emotions, advise one-on-one in private, and help define the solution, you’ll improve the product and enable the team to take full benefit from your insights.