Mentoring has nothing to do with managing. There is a dire lack of mentoring in the software industry. The pace of change is amazingly fast. So many conferences and talks are available to watch and learn from. Articles on how to do X, Y, and Z are constantly written. Documentation is improving because folks who write developer tools and platforms know that if your docs are bad no one will be able to learn how to use your amazing service. And all of this is free, I haven’t even mention paying for bootcamps or Udemy courses (though really, stop advertising classes at me in YouTube).
But none of that comes close to mentorship. I don’t have a mentor. I wish I did (any volunteers?). I don’t have anyone junior to me that I am truly mentoring (Bueller?). The statistics tell us that older programmers are being passed up for jobs. While all the problems we are solving are the same ones we’ve been working on for decades. They have so much knowledge and we are watching it walk out the door. Will we ever learn everything they learned? How much will be forgotten, and re-solved with a worse method?
Plenty of companies add some element to their job descriptions that sound like “mentoring”. My current gig has it. I bet if you took a poll less than 10% of people would say they are actively being mentored.
I do know that people a few rungs up the ladder have mentors. And they are usually long-lasting relationships.
The job of mentoring someone is, in my opinion, antithetical to being their manager. Once a person has the power to promote or fire you, the relationship to that person fundamentally changes. That changes puts in place a barrier to effective mentorship.
I can only tell you what others have told me. A mentor is a person you can use as a sounding board. You can tell them what you’re thinking and feeling around your work. You can tell them what you’re trying to do about it, and if it’s working. And they will use their experience and keep you on track. To use a musical metaphor they are your sound-check—make sure everything is working and in-tune.
The content is necessarily is specific to the individuals and situations. But it is a professional relationship between two people that is not hierarchical. Often these people don’t work in the same company.
I can definitively say that mentoring is not “I can’t figure this out, can you help me?” Helping someone you work with is something we should all be doing, but it is transactional in nature. Nor is mentoring venting about your work situation with someone else behind closed doors.
I believe if we had more effective mentoring we might realize several things:
These are all things our industry desperately needs.
Read more: More Mentoring
Tech Debt won’t kill you. I firmly believe that. However, I realize that people believe certain things are “technical debt” when they really aren’t. This happens because they don’t have another term to capture what is happening. So they turn to “tech debt” as an umbrella term.
Let’s stop doing that. Let’s offer up another phrase to more accurately capture what is happening.
Technical debt are decisions that will eventually need to be re-visited after a certain amount of time. On a long enough timeline, every single thing is technical debt. Eventually even computers will change so fundamentally that you’ll need to change even the simplest code.
But some decisions escalate risk. That is not technical debt. Even if it is a technical decision in nature, it is not debt. It won’t eventually become a problem. It is a problem in the very moment you’ve made the decision.
This is why technical debt will not kill you. Escalating risk will absolutely destroy you, your product, and your company. Here are a few things I’ve experienced that escalate risk.
Sometimes it isn’t even about code. All business systems include the humans that use those systems. A lack of communication between the people changing the system (engineers) and the people using the system is one of the riskiest propositions of all. That goes both ways. Without managing changes, explicitly, on how people are going to use the system differently, or what changes are being proposed is going to cause chaos.
I have seen corner-cases ignored with the explicit statement of “that won’t happen”. I guarantee you’re wrong, I guarantee that it will happen. Once it does happen you better have an answer. There is a clock running from the moment you deploy until that corner-case is hit, and you have zero control over how fast, and how randomly that clock ticks. The bigger your system and the more people are on it, the faster it ticks. Its one thing to not address a corner-case, but one surefire way to make it worse; not even alerting within the system that the corner-case was hit.
Those are some higher-risk examples. But let me give you a lower-risk example: not enough logging. Once a system is even close to something we consider “complex” there will be unexpected errors. Errors that don’t seem to be possible. Errors you cannot possibly hope to reproduce in dev. Errors that won’t stop. If you don’t have all the data you need to solve it at hand, you’ve added just a little bit of risk. If you’re experiencing this problem now I highly recommend looking into honeycomb.io (Disclaimer: I do not work there, they are just that awesome).
Read more: Not Everything Is Tech Debt
There are tons of opinions and ideas on how to get software engineers to work together, and I’ve shared some of my own before. I think the crucial one to get right is coming to the idea of a Directly Responsible Individual. Whether it is a bug, a feature, a service, part of a product, or the whole product (for smaller products) there should be one DRI.
I believe this the most effective, and most natural way to do our work. I believe this is, more or less, how open source projects tend to work. Single individuals own features, parts of the project, bug fixes, and processes. And decisions flow through those individuals.
It is very simple. The DRI is the source of truth for that indivisible thing. And “indivisible” is how you decide how many DRI’s you need to have. The DRI is where the buck stops. They are fundamentally responsible for what they are given to work on. For a sports example; the coach is the DRI of the team, when the team fails to perform the coach gets fired. Why? Because there was zero question who was responsible for the on-field performance of the team.
The DRI gets the final say. You can imagine this as if they have a 51% voting majority on every part of their project. Ownership in the strict sense of the word. They should, of course, ask for input, feedback, and opinions from others on their team and others not on their team. The individual knows their piece is but one piece of the greater whole, and everyone is working towards reaching the final goal. But the decisions ultimately rests with them. Why? Because the responsibility of delivery rests with them. You cannot give them full responsibility without full autonomy, otherwise you’re sabotaging them from the start.
The list of responsibilities you give to the DRI is up to you. If TDD is important to you, make it their responsibility too. If you want them to fully document their project, from goals to decisions to user training, go ahead. If you don’t have a dedicated DevOps team you can make it the DRI’s responsibility to manage the project in production. Of course, if you have a DevOps, or a product team responsible for documentation, or a QA team, etc, those teams ought to have their own responsibilities. Make the lines crystal clear.
Whether everyone works on their own, is paired up, or a mix of the two there should still be a single DRI. If you’re pairing, give them each a related thing to own. And they can switch during the day as to whose project they are working on, who is making the final decision.
Whether you have teams of three, or teams of eight, or twenty, you should be able to chop up the work into indivisible pieces. Naturally, there will be pieces that have to work closely together; two different pieces sharing the same data store and data models, many pieces using one API service, etc. But so long as you have defined and documented interfaces, you can surface discussions around a ChangeLog when things need to change.
I believe this works because owning what you’re working on gets you invested in doing a good job. It’s yours, no one else’s. Since it doesn’t belong to anyone else, it will reflect you and your choices.
There can be no buck-passing; “Oh, I thought someone else was going to do that,” and there can be no wondering about why something didn’t get done. There can be no disagreement as to how something ought to work, because one person makes that decision. The only question becomes: is it performing?
This makes management’s job much clearer; they now have one job and that job is to set context. Your manager, or lead, doesn’t have to wondering whether or not they should “jump in” and help you out. You can ask them. When you feel they are deciding things for you, you get to say: Thank you for your input, I will make the decision. Both micromanagement and drive-by-management need to be shut down, because it is no longer their job to make decisions. Their job is to set the context.
Management needs to give you the reasons why we’re doing this work. They need to give you the end goal, the job your software needs to do. They need to tell you what you’re starting with, and where you’re headed. They don’t get to decide the path you’re going to take.
Read more: A Responsible Individual
An adjective everyone wants to claim: resilient. “Our service/platform is resilient.” Resilient infrastructure is a topic that many have gone into detail to teach us all how to achieve it.
But I think we have skipped over something. Something more fundamental. Conway’s Law:
[O]rganizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.
If you’re looking to build a resilient system, you better have a resilient organization, and communication, otherwise you’re going to be ice-skating up-hill all the time. You may yet achieve your goal. And then one day you’ll realize you’ve slipped and lost that resiliency.
It comes down to actually creating a culture in your organization that truly values resiliency. That is the only way you can be sure you’ll continually reach your goal.
The biggest success story for this topic is Amazon. The first goal wasn’t resiliency, it was about pleasing their customers. But, Bezos knew without a resilient system the customer experience was always subject to volatility. We all know what he did. He separated his teams.
He demanded that when his teams communicated with one another they did so through official channels. Just like any other customer would. In order to be absolutely sure the customers would be treated well—he turned teams at the same company into customers. This is a rather extreme, and useful, form of “dog fooding” (using what you build).
Rather than just telling everyone to “Be More Resilient”, as if that is a thing you can expect to work, he introduced a constraint that resulted in changed behavior. And the result of that behavior was very resilient systems that are highly regarded by everyone in our industry.
Read more: Resilient Microservices
Search is a fairly solved technology these days. Google reigns supreme for searching the internet “writ large”. Since they’ve done such a good job all the e-commerce and product sites have learned how to do it well. It is not hard to find the things you’re looking to buy.
But what about knowledge. And not just any knowledge—specialized knowledge. The knowledge that you and your organization knows. The kind you don’t want anyone else to know about. It’s not necessarily “Top Secret”, but you don’t put it on blast for everyone to see.
Searching your own institutional knowledge is hard. After all, that is why it is still useful to “know where the bodies are buried.” Because institutional knowledge is hard to find out. Part of the issue is that the search corpus is often spread out, between many tools and data sources. A lot of it is never written down. And if it is written down—are you willing to bet money it is up-to-date and current? I wouldn’t.
Like I wrote about in Shared Understanding, Imperfect Representation:
There are lots of good tools now to understand what your system is actually doing. There are lots of good tools now for understanding what your users are actually doing. But within your team(s) no one person has the big picture. Everyone has a part of the model of how things ought to work. Stitching that together repeatedly, with little margin for error, is very, very hard. There are not very many tools that are specialized for that.
This is not simply a Software Engineering problem. This is a problem with all Knowledge Work. Why? Because there is no external referent for knowledge work. It is all concepts that live in our heads, relationships that exist between us, and words exchanged in person or written down. You can’t see this work like you would see a building in progress, a car on an assembly line, or even a bike being assembled in your local bike shop.
There are many tools out there that people are using, but no one likes them. None of them actually achieve the goal. I believe there are three reasons.
The first reason is that I don’t think they’re focused on the process—they’re focused on the output. Wikis and word documents presume that you’ve already come to a conclusion. This is why you have seven word documents all named the same with various “final-v1”, “v2”, “final-final” on the end of them. This is a learning process, not a static end, recognize that.
The second reason is that these tools are too hard to get your thoughts out quickly, so people don’t use them. The tools ask too much of you up-front. What is the title, what kind of template do you want, what category does this belong to. Meanwhile you’ve got a nugget of knowledge burning a hole in your skull just trying to get out onto the page before you forget it or get distracted by the next thing.
The third reason is culture. There is value in being the person who knows where the bodies are buried. There is value in scarcity. If you don’t have a culture that values collaboration and writing things down I hope you’re not holding your breath on being able to find that one thing you’re looking for.
Read more: Finding Information Is Hard