NOTE: This is part of the tech lead academy series. This post contains mostly raw notes from the course I took from Kent Beck.
There are a lot of ways to be more effective at your job as a lead. Here's seven that are high leverage:
- Be proactive
- Begin with the end in mind
- First things first
- Think win-win
- Seek first to understand
- Build networks
- Sharpen the saw
As a lead, you should be going out and finding important problems to solve. To do so, you need to get yourself in the right mindset.
Focus on unblocking yourself: Fetch some data to understand things better. Ask yourself probing questions:
- What are the next steps?
- What happens if we don't do the work?
- Is there a workaround?
- What is actually blocking us?
- How can we make progress?
To gather more effective answers here, start hard conversations with others. If it's taking a while, take a break. Sleep on it. Work on something else for a while, and come back with a fresh brain.
You should be less of a task monkey, and more of a lead: make calls on what to do, and explain why.
Venn diagram showing concern and influence, with the suggestion to find areas where you have both.
As a lead, you should primarily be focusing on areas which both concern you and where you have influence over. These are areas where you can actually have an impact and make changes. You should avoid concerning yourself about areas where you don't have influence - this can often cause anxiety. Also, don't try to influence areas you're not concerned about - offhand comments can cause a lot of issues.
Kent talked about a story where being proactive could be a bad idea. There was a student working on adding compression to a database [ tech details left out ]. The student found another area of improvement, and made it their concern, but they had no influence/interaction with the relevant people. The net result was that they got banned from databases groups and from emailing two specific people. This is despite the fact that the long term idea was a good one (and indeed, the newer DB solution used similar ideas). It was important to be proactive, but it needs to be done in the right manner.
Think about the big picture: What do you want written on your tombstone?
For example, for Kent, his motto is "help geeks feel safe in the world".
Then, have a plan to get there. Define what success looks like for you, combining qualitative goals with quantitative metrics - so that you have a way to measure progress.
Don't hold yourself too strictly to metrics though.
Programmers should use metrics like drunks use streetlamps: for support & illumination. Spend time at one for a while, and move on eventually.
All of software engineering is basically like salami slicing. Take a big thing, slice it into manageable chunks, decide what to eat first, and then eat it. You can always slice something even smaller.
You should be flexible about ordering and slicing things thinner, so you can get feedback more quickly and iterate faster.
As you do this, focus on things that are important and urgent - and then things that are important and not urgent. Try to avoid work that's urgent but not important as much as possible
As you do this, bank progress: build things in parts and continuously deliver impact. You can then bank on that success to get help and support to do even more.
As a junior engineer, you may be used to only seeing one side of things in a conflict, i.e. just the benefit of your side. Over time, you'll learn to see the tradeoffs inherent to any decision. Eventually, you should transcend that and go to finding win-win opportunities: meeting everyone's needs.
It's not about compromise -- that should be your last resort. Take the time to apply some creative problem solving skills and look for alternative solutions.
Win-win involves changing the rules of the game
When you run into a conflict, be specific: "You want X, I want Y, these seem like they're in conflict. How can we proceed?". Don't pretend to agree to avoid the conflict, that only leads to problems down the road.
You have to trust me before you're willing to listen to me -- and so, you should aim to understand where people are coming from first. Spend time to understand their mindset and workflows.
This might appear to be a paradox: Your job is to convince others, and you're being evaluated based on your ability to do so. But you can't convince other people if they don't listen, and you can't make them listen.
To have influence, you have to be understood. To be understood, you have to understand.
Try clarifying your intent: Are you trying to form a deep understanding of their needs? If you don't want to understand, things probably won't go well.
Building networks is really important to expand your sphere of influence. Spend time in hackathons or other activities - it's an opportunity to meet people you don't know and learn about things you don't know about.
Make friends with your colleagues, building that social connection helps with work as well.
Avoid the common fallacy a lot of new engineers have:
I was promised that if I understood this machine, I'd never have to talk to another person again
You need to constantly be learning and growing to become more effective. Spend time working on yourself and your tools, i.e. sharpening the saw.
80% of your work time should be spent on low risk, medium reward projects.
15% of your time should be spent on high risk, high reward projects. Most of these will fail, and that's fine! This time should be used to sharpen the saw a little bit, but focus on some fun projects.
The last 5% of your time should be spent on totally random stuff that interests you. These will almost never work out, but when they do, holy shit, it's amazing. Work on whatever you're curious about, this is time to spend on sharpening the saw.
As you work through your 80%, you can make solid progress towards a lot of work items and teach others. By the time you get bored, your 15% projects will probably succeed and become your next 80% project. Every once in a while, one of the 5% projects will succeed and give you a new direction for your career.