At some point in your career, you will probably sit in a room and realize that you know more about the topic of discussion than anyone else. It might be some piece of functionality, a current bug, or maybe something larger like an entire system, business model, or technology. I challenge you to share everything you know.
Some practitioners view their niche specialty as their ability to have: job security, higher wages, better title or some other intangible prestige. It's easy to understand. It's nice to hear these things:
"I hear you are the expert at..."
"Our company would be really screwed if you ever tried to quit here."
"Wow, without you in these discussions, we could have made a big mistake with our assumption."
And we also have the fear of being forced to share our knowledge. I get it. I mean if everyone could do my job, I wouldn't be able to have a job.
When we start our technical careers, we have a small amount of knowledge. Whether through a degree, certification, or DIY knowledge, we have a glimmer to show that we can work in the technology field. There is an assumption that new employees, especially new to the field, will require training and ramp-up time. We have to teach you all the specific stack, development lifecycle, and codebase to be able to do your job. Your value to the company grows tremendously in the first year.
Let's talk about what that value can look like to a company:
In the x-axis, we have the number of weeks that a new software engineer has been at a company. The y-axis is value to the company. We have the grey dotted line, the best employee currently at the company as a baseline. Finally, we have three different curves representing different scenarios. This diagram is not exact, but is here to illustrate some principles.
The first is the somewhat common expectation that is baked into many project plans: new software engineers will provide the same level of output/value in a negligible amount of time. It's obviously wrong, but used much of the time because: it pushes the team to output more, it is difficult to actually calculate individual contribution levels as they onboard, and it looks good to upper management that their newly hired employee was worth the money.
The second situation is "most companies." If you think you are not in this group, you probably are. Here are some hallmarks of the vast majority of companies:
- Waiting for your equipment to arrive.
- A generic onboarding document/checklist.
- Multi-day get my system setup process.
- Multiple: "How do I get an account to this system?"
- Being given simple tasks to complete on your own that grow in complexity over time.
- Being put on support with and having the anxiety: "Oh my God: who do I call if I get an alert!?!"
The final line is one where an employee quickly provides value, but then can also grow above the current best employee. I have worked at a number of companies, but only one where I felt like I was in the red curve. This is where I was with a team that wanted to share everything that they knew with me.
I am quickly going to say that sharing everything I know is bounded to the context of your profession. Not necessarily personal life. This can happen in a sharing culture but isn't required.
There are many ways that we can share our knowledge. I'm going to boil it down to three different methods:
- Writing it down.
- Sharing it verbally.
- Practicing it together.
Writing It Down
This I feel is the most difficult and provides least amount of value (most of the time). Writing is difficult. It requires practice to write well formed sentences. It is difficult to form them into points, arguments, and ideas. It is hard to know your audience. Most of the time, if you publish on the internet, anyone can be your reader.
Secondly, many finer details take up so much space to explain them that you have gigantic volumes written. These include:
- Technical manuals.
- Textbooks.
- RFCs
- Enterprise software documentation.
The vast, vast majority of people don't read these through. They just don't. I have written many technical guides, designs and documents that are very thorough and never read. Bleh, what a waste.
I think the one shining exception of this is https://stackoverflow.com/. This is where very precise questions can be asked and then precisely answered. All of us software engineers live and die by this site.
Lastly, I think that their is an incorrect assumption that writing it down will make it last forever. Yes, there are a few timeless classics out there, but most of the time not. Most written documentation is out-dated, and incorrect.. We move too fast and change too many things. We write documentation after we do something. Many people would rather no documentation than incorrect documentation.
Sharing It Verbally
Verbal sharing I think is an improvement in many ways to written. It's easier to talk than to write for many people. We usually talk more than we write. We often have a single audience, or a group that we know. Occasionally, we get to speak in front of a larger group that we don't know, but that is more the exception than the norm.
I like sharing my knowledge verbally because I can also get feedback. Non-verbal head nods are some, but also questions, comments and affirmations. I can repeat the same idea in different ways until the audience tells me that they understand.
This can also hone my understanding of what I am sharing. People ask lots of questions that I haven't thought about. It makes me figure out the answers and grow deeper in my knowledge.
Some may not like verbal knowledge sharing because it is temporal. "You would have to repeat it over and over again." Yes, but that assumption is that knowledge is shared by just one person. If everyone is doing it, then it spreads more like gossip.
Practicing It Together
This is my favorite way to share knowledge with other people. I find it to be the most rewarding and the most impactful. Rather than I tell you how to do something, let's do it together.
I do this in a couple of different ways:
- pair sessions
- mob sessions
- lead the way
In a pair session, we just sit down and do something together. I can "drive" (use the keyboard) or you can. In longer sessions, we switch out. I encourage anyone that I am pairing with to ask any question they have. I get many of these:
- "Why are you putting that in a different function?"
- "How did you do that?" (Using an IDE function)
- "Why did you start there?"
- "What will that do?"
These don't have to be long, or 100% of the time, but I can take an employee on the first day of their job and pair with them and we can get work done. If I pair with them, their onboarding grows exponentially. Also, the majority of the time, they know something I don't. I get to learn everything you do when we pair.
In a mob session, we just expand the idea of pairing to just have a larger group work together. This can seem even crazier to a project manager. "You mean that the entire team is going to work together on a single ticket!?" In a mob session, I will define the goal: "We want to build a dashboard for our new feature." I will typically have two TVs hooked up to computers: one for writing code, and the other for googling any questions (Stack Overflow). All other laptops are banned. We pass the keyboards to the right every 5 minutes. All people in a session must participate. It forces everyone to pay attention because their turn is going to come up.
Lastly, I like to lead by doing. As a lead engineer, it is common for me to start a new team/project. I will setup the codebase, linting, automated testing, pipeline, deployment, alerting. All of it. And I do it with the newly formed team.
Need to do a zero-downtime deployment?
I'll show you how to do it.
Want to know how to develop a SLO/SLI/SLA for your service?
Let's do it together!
Want to do something that you have no idea how to do?
I don't know either, but let's figure it out!
I personally won't stay on a team for longer than 6 months. Most of the time, we have gotten the major pieces working together. The first several releases are done. Support has been figured out. The team dynamics are known. I just take a step back and let the team do their thing.
Wrapping it up.
At the end of it, I have plateaued in many of my technical skills. There are new things to learn here and there, but my value doesn't grow now based on how much technical knowledge I have. My value grows now by sharing it with others. The real value growth is that if I can teach others to do what I am doing. Teaching others to share their knowledge as well makes my value exponential. If I share 10 things with 10 people this year, and they each share those 10 things with 10 others.
My value to a company grows most when I share everything I know.
Top comments (0)