What value do you bring to your company?

In an open organization, you should be ready to answer this question—at any time.
No readers like this yet.
Leaders are catalysts

Opensource.com

Imagine you're caught in the elevator with the Chief Financial Officer or CEO of your company. They look at you and ask, "So, what value do you bring to this company?" Hopefully the senior leaders of your company don't enjoy asking intimidating questions in the elevator, but this question, I think, is completely fair; everyone should be able to answer it confidently.

As someone leading a team of 100 people spread across four continents, I spend a significant amount of time helping people understand why we're doing our work in the first place, and why the work each of us does is critical to our company's success.

Leader as catalyst

In The Open Organization, Jim Whitehurst says leaders should be "catalysts." Jim and other Red Hat leaders frequently talk about our high-level strategy—the areas on which we need to focus in order to be successful as a company. Jim isn't telling everyone what to do; he is simply painting the picture of how he thinks we can be successful, hoping to "light little sparks and see what passionate fires erupt from there." Departmental leaders have the challenge of determining how their teams can most effectively contribute to that success. Nobody is telling me (a middle manager at Red Hat) what my team needs to focus on—that's part of the open organization culture. I get hints about where to focus by looking at our company strategy, listening to our leaders, getting feedback and context from internal stakeholders, and by talking with customers. My role is then to convey to the team what I'm learning in a way that translates to the work they are doing every day.

I don't want to tell the 100 people who "report up to me" what to do any more than they want to be told what to do. Instead, I want their help figuring out how we can best use our capabilities to contribute to the company's goals. In our case (as the team that creates Red Hat's product documentation) we have a direct impact on the customer experience—and becoming more customer focused is one of our major company initiatives. But, there's still a lot of room for interpretation: exactly how does our team improve the customer experience? So I started a discussion by throwing out some ideas and asking for input. I got a ton of feedback—some of it emotional, some of it challenging (all of my "starter" ideas represented change), but all of it contributing to forward progress. After several weeks of discussion, we arrived at a single goal to focus our efforts. It was a compromise. By a long shot, this one goal doesn't solve all the problems we need to solve. But it is a good starting point, and realistic in scope for the next year. And most importantly, it's something everybody could buy into and contribute to.

(For the curious: the goal is to create an awesome "getting started" experience for each of our products through content. The goal itself leaves much room for interpretation, but the intent is clear: We must help customers have an easier time adopting our technology.)

After we worked as a team to establish this goal, I spent some time visiting different offices to talk about the goal, what it meant, and how we could all contribute to it by setting personal goals (in other words, to give people ideas on how they can add value by directly contributing to our company strategy). At one of these sessions I was a little surprised to get this question: "What are your goals for the year? Can you share what's in your own development plan?" The question caught me off guard. I hadn't finalized my own goals yet, and here I was telling the team how to set theirs. The question put me on the spot, but I knew it was a fair question and was happy someone asked. I answered as honestly as a could at the time; I said I hadn't finalized my personal goals yet but I was working on it with my manager and I would soon post them for everyone to see.

Keeping leaders honest

The idea of openly posting my personal goals was a great way to "keep me honest," and it spread more widely than I would have thought. Inspired by Google's OKR methodology, large percentage of the worldwide team has now posted their goals and weekly progress updates for anyone to see.

Much has been written about goals and how (or how not) to "manage performance." My general feeling is that the "typical" approaches don't work (i.e. having people go through the motions of an annual development plan, self-assessment, and manager assessment, when they don't really see the point). At an open organization like Red Hat, people won't do something if they don't see the value in it, and I've heard plenty of Red Hat associates talk about how meaningless they find the ritual of setting goals to be (because, I believe, they haven't personally seen the value).

But, I know from my own experience both individually and as a manager that setting goals that tie directly to the team strategy can be a critical part of the team's success; it helps ensure each person can stay focused on team or company accomplishments without getting lost in the "urgent but not important" work that always piles up. Ultimately, my most important goal is to make sure each person on the team understands why we are doing what we do—as well the value of their personal contributions.

Picture of Sam in his home office smiling at the camera. Sam is a white man. He has long curly brown hair and is wearing a dark green zip up fleece hoody.
I lead a team in Red Hat focused on providing context, knowledge, connection and alignment to our Product and Technologies employees, as well as working to ensure they have an inclusive, equitable, and safe environment to work and grow in. I am a late-diagnosed autistic person and I co-chair Red Hat's neurodiversity employee resource group.

5 Comments

Very interesting to see how the open org works within a documentation department. I like the idea of one overarching goal and wonder if the typical annual goal setting should mimic this single goal, and list the rest of the yearly items as what they are - project deliverables.

Sandra - thank you for the comment. In general, I try to get away from annual goals because in reality it's hard to carry something on for that long, and at Red Hat things change so fast we need to adjust individual goals more frequently. In this case, the department goal is broad enough to work, but individual goals would be more specific and also more agile. In terms of goals vs. project deliverables, I think of it as "activities" vs. "outcomes". So, all the activities you do day to day, should add up to some bigger outcome - that's the goal. Otherwise I feel we end up working and working and losing sight of why.

Great and interesting read, especially the connection with the concepts in The Open Organization.

I was confronted with the question in the title albeit in a different manner than Sam poses. Recently I was a panelist for a discussion on how certain roles function within Red Hat. I have a good answer about what I do, but that answer does not do a good job of addressing the value I provide. The question gave me pause and ended up being an excellent opportunity to reflect on why I do what I do.

The experience got me to refocus my energy on having impact rather than on "doing stuff". Exploring the answer has strengthened my belief in the value I create. It is great question to ask and one I plan on asking myself repeatedly.

Oh yes, that was a key point for me as well - what is my value to the company. What I've come up with so far is that I make the complex understandable.

...it's a work in progress as far as a value statement goes, but it's a start and something I hadn't thought about before reading this article :-)

In reply to by Keith Watkins

I like your statement. It is more succinct than mine while conveying the same sentiment. Mine thus far is "I transform data into information in order to enable decision-making."

As you say, it's a work in progress.

In reply to by Sandra McCann (not verified)

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.