Being Right vs Being Pragmatic

An Order-of-Operations Problem

People rightfully respect experts in any given field.? But they respect leaders with expertise even more.? This is a subtle difference but making the right decisions in critical collaborations never goes unnoticed and will position you for top leadership roles later in your career.

Let’s study an all-too-common scenario.? Suppose you are the leading expert in a specific technology within an organization and it becomes very visible to senior management.? Usually, this means it’s important to strategic go-to-market or revenue-generating goals.? Congratulations, you are in the driver’s seat!? The spotlight’s on you and it’s time to shine.

First and foremost, you must recognize the gravity of the situation.? Assume that if a senior manager or executive ends up copied on an email thread, this is it.? If you’re not sure who the person is or what role they perform, look them up.? Most companies have a convenient directory.? If not, search for their name in your favorite professional social networking platform.

Second, “read the room” by understanding the context of the conversation.? Is it about a customer or a “compelling” event?? If so, and a senior leader is copied, assume it’s mission-critical – e.g. tied to quarterly revenue targets or specific strategic deliverables.? If the thread is simply a question or clarification, don’t assume it’s not important either.? Most senior leaders don’t spend too much time on routine back-and-forth between individual contributors unless perhaps it involves some sort of conflict resolution.? If someone is just copying their manager (or yours) because they are having problems getting what they need from you, then you can treat the communication as tactical and try to be helpful without necessarily going out of your way.? Be clear in your response in terms of what your capacity is and try to resolve the issue in the most practical way possible, whether that’s answering a question or taking the opportunity to “train” the requestor (without condescension).? Regardless of the reason for a request, being perceived as helpful is always better than just being the “guru” that everyone dreads communicating with.? If you’re helping, you’re adding value.? This too does not go unnoticed, especially when visible to management. ?Earning the respect of your peers, however, is paramount to eventually becoming their leader.? Remember that leadership is earned, not given.? Strive to be a leader, not a manager.

Third, take the opportunity to share knowledge.? Don’t lead off your response with a novel about the right way to “do” something but provide helpful links to reference materials or previous conversations in the appropriate context.? Avoid writing things like “as I said before” or “as I already explained” – as irritating as it may be to have to repeat yourself, it’s a sign of level-headedness and emotional intelligence to do this concisely and without negativity or perceived reluctance – again, a critical attribute of a true leader.

And here lies the decision point.? Your response has two parts – the solution, and the knowledge transfer.? If you start with the knowledge transfer, you are being “right” because the person making the request should likely learn how to accomplish whatever they asked for themselves.? This is especially true of your peers with similar skill sets.? As a software developer by trade, I know how irritating it can be to provide an answer to a fellow developer that is obvious after spending less than five minutes looking at readily accessible source code.? Even more irritating is doing this when responsibility is in question.? For example, if you sent a helpful snippet of code to a peer to help them finish a project, and they never took ownership of it.? But if you start with the lecture and then begrudgingly provide the solution anyway, you are seen as pedantic and abrasive – definitely not leadership qualities in any successful organization.? If you just respond with the lecture and no solution, you’ve communicated to the world that you are unapproachable and your value to the organization drops significantly over time.? Unsolved problems are not useful – eventually, business needs dictate looking for other solutions, and people stop asking you.? At this point, you are just collecting a paycheck, and likely redundant regardless of how elegant your technology may be.

If on the other hand, you start with a very pragmatic and direct solution, even if simplified or illustrative, and then provide the knowledge transfer, you are seen as both a problem solver and a teacher.? Even if you cannot solve the problem immediately, because you have a lot on your plate, be transparent about this and try offering advice “in the meantime”, in case the requestor needs this to solve something immediately.? This is better than projecting antagonism over the request in the first place.? If you have time to write a nastygram, you probably have time to be useful and help solve the problem instead.

Ask yourself whose organization you’d rather be part of – a technical expert who admonishes you for asking what they perceive to be stupid questions that you should know the answers to, lectures you with reference material without context, and then sometimes provides a possibly effective but explicitly condescending solution?? Or perhaps an emotionally intelligent teacher who may not always have the capacity to solve every problem immediately but takes the time to answer questions pragmatically and without judgement, and happens to be an expert that everyone respects equally for their demeanor as for their knowledge and experience?? Admittedly these are caricatures – the former never earns a leadership role and the latter is a “unicorn”. ?No one is either wrong all the time or perfect – but try to be the latter as much as possible.? In short, a leader helps solve problems while also taking the opportunity to teach.? An “expert” lectures to reinforce their self-importance or sense of “right” versus “wrong”, while sometimes also being begrudgingly helpful.? Both approaches take similar levels of mental effort yet only one demonstrates the right sense of business priority.

Being pragmatic and solving problems on highly visible collaborations demonstrates a commitment to business objectives versus a perceived obsession with trying to be the “smartest person in the room”.? Stakeholders notice your willingness to help and understand the mission-critical nature of situations versus the possible laziness of requestors asking you to do something they should be able to do themselves.? So, what do you think happens down the road when the organization looks inward to find the next generation of leaders?? If you guessed that a commitment to and understanding of critical business objectives is high on the criteria list, along with good people skills, you’d be right.

In Blueprint Seven Six, I write a lot about being pragmatic in the context of building software products and organizations by doing less and prioritizing more.? This is critical to driving business value with limited resources.? But you also need to detect when the pragmatic route is to go the extra mile, especially when high-ranking eyes are upon you.? The difference between problems being solved quickly or late (or eventually not at all) can mean the difference between remaining (one of many) experts or becoming a respected and impactful leader in the not-too-distant future.? Choose wisely.

要查看或添加评论,请登录

Leo Reiter的更多文章

  • Balancing the Value Equation

    Balancing the Value Equation

    Always add, never subtract. For as long as we’ve had technology startups, we’ve known one thing to be true at the early…

    2 条评论
  • The 2 Things that Really Matter When Choosing a Startup

    The 2 Things that Really Matter When Choosing a Startup

    So, you’ve decided to join a startup – congratulations! Startups are uniquely wonderful experiences that everyone…

    3 条评论
  • Your Software is Not Your Baby: A Story About Letting Go

    Your Software is Not Your Baby: A Story About Letting Go

    If only I had a dollar for each time someone referred to one of my software creations as “my baby”..

    8 条评论
  • Process Meets People: My Long Agile Awakening

    Process Meets People: My Long Agile Awakening

    My first true exposure to Agile was in late 2009, but I can honestly say it took me almost a full decade to…

    1 条评论
  • Technical Debt in a Nutshell

    Technical Debt in a Nutshell

    Technical debt is not some mysterious concept nor a convenient scapegoat when businesses negotiate schedules with their…

    3 条评论
  • The One Product Compromise You Should Not Make

    The One Product Compromise You Should Not Make

    Successfully navigating complex situations, whether they be interpersonal relationships, investment strategies, sports,…

    4 条评论
  • Introducing Culture

    Introducing Culture

    Culture is a hot topic, especially in smaller firms and startups. Social responsibility? Mutual respect? Fanatical this…

    1 条评论

社区洞察

其他会员也浏览了