Posts

Influence, part 5 of 5: Organizations

 This is the fifth part of a five part series on influence as a Staff+ Software Engineer ( part 1 ,  part 2 ,  part 3 , part 4 , part 5 ).  I've ported this here from where I  originally published it on Medium .  Organizations Organizational design patterns For Software Engineers who’re senior individual contributors (ICs), the main pattern that seems prevalent is that a senior IC and Engineering Manager work together to share the responsibilities for running a team; often the IC will be called a Tech Lead (TL) or Uber-TL. If you don’t plan on managing then it’s worth thinking about how that will impact your career and the sorts of roles you can and can’t take. Skills take time to acquire and you have a finite amount of time to do so! While it may be possible to stay an IC at some companies and not be a Manager that’s not always possible. Likewise, switching from TL -> TL-and-Manager or TLM -> M shouldn’t be done lightly. You can definitely...
Post a Comment
Read more

Influence, part 4 of 5: Tactical tips

 This is the fourth part of a five part series on influence as a Staff+ Software Engineer ( part 1 ,  part 2 ,  part 3 ,  part 4 ,  part 5 ).  I've ported this here from where I  originally published it on Medium .  Tactical tips Give credit If in doubt, add a credits section to your docs and presentations to thank the people who have worked on something with you. It’s likely that you’ve been talking to them to refine your ideas and make plans, and it’s only polite — they’ll be far more likely to work with you in the future and share ideas. The combined wisdom of these people is likely to be greater than your own. This shouldn’t be a zero sum game, even when it comes to design docs for perf. It’s entirely fair to ask others to also include credits sections. Write the doc and know how to circulate it If you have a good idea then put it into a one page doc. Bonus points if you can actually make it one page long! This is good for a few reason...
Post a Comment
Read more

Influence, part 3 of 5: Yourself

 This is the third part of a five part series on influence as a Staff+ Software Engineer ( part 1 ,  part 2 ,  part 3 ,  part 4 ,  part 5 ).  I've ported this here from where I  originally published it on Medium .  Yourself Know & grow your credibility There’s a large difference between working with people you know well and people who you have just met. Once you’ve worked with someone for a while you’ll have a sense of how they work — the hours they keep, what they’re especially good at, what they like doing. Building this sort of relationship is easier if you’re working with someone frequently but it’s tricky when you’re just starting to work with them. There are a few tricks that work well to get this started on the right foot — one of the best is to have someone who knows both people introduce you. Don’t be afraid to ask someone to do this as often it lends you a small amount of instant credibility. Train your weaknesses, apply yo...
Post a Comment
Read more

Influence, part 2 of 5: Research

 This is the second part of a five part series on influence as a Staff+ Software Engineer ( part 1 ,  part 2 ,  part 3 ,  part 4 ,  part 5 ).  I've ported this here from where I  originally published it on Medium .  Research Understand what already exists In large companies there may be several teams thinking about similar problems. It’s incredibly useful to understand what’s already out there and how much of it can be reused. It’s not easy to find though. Once you’ve found something similar to what you want, you need to decide whether you want to reuse it as it is, or borrow pieces, ideas, or build something new. My personal bias here is hugely towards not wanting to be oncall for a custom service so I far prefer to use existing infrastructure that another team owns. This doesn’t always work. One thing you need to be especially aware of is the reporting chain of an infrastructure team you rely on — if they don’t at least end up at the ...
Post a Comment
Read more

Senior to staff engineer curriculum, part 4 of many: Conway's law

Session 3: Conway’s law and org structures Please read: https://www.productbreaks.com/p/dont-cave-to-conways-law [Hat tip to Enrico for the suggestion of this topic] Prompts for discussion: What are the missions of our teams? How do those, and the gaps between teams, show up? Suppose you want to work around Conway’s law, what else can you do beyond what’s suggested in the doc? Talk to people, is the main one Joint OKR planning Rotating people through teams Scary: propose a reorg Homework <None from this point on, as nobody was doing it anyway and it was optional.>
Post a Comment
Read more

Senior to staff engineer curriculum, part 3 of many: sources of power

  Session 2: sources of power Please read the summary of the book at the bottom of this post. (I couldn't find a good doc to link to so I wrote this instead.) Prompts for discussion: Have you seen people fall into the trap of expecting something to happen because they have the most knowledge?  What happened? What type of power convinces you? Do you think this is the same for people in other roles? What sources of power are you personally long on? Or short on? Think about the last meeting you were in.  What sources of power did each of the people have in that room? If you’ve changed jobs or teams, what did you notice about the change in your sources of power during that period? Homework: Notice sources of power and people using them.
Post a Comment
Read more

Senior to staff engineer curriculum, part 2 of many: Delegation

  Session 1: delegation Let’s talk about different types of delegation.  Please read: https://medium.com/@jurgenappelo/the-7-levels-of-delegation-672ec2a48103   Prompts for discussion When people delegate to you, what level are they using? When you delegate to others, which ones are you using? How is this different for Senior compared to Staff engineers? What happens if you think you’re using one and the other person thinks it’s a different one? How can you tell when you’re at the wrong level? (I.e. micro or macro managing) How do you set up guardrails after you’ve delegated, to make sure things are on track? How is delegating to LLMs different to people? Homework: The next time you’re delegating, or being delegated to, pause and think about which one of these levels you’re at.  Then, confirm it with the other person and see if you’re right.
Post a Comment
Read more