(Reorganize this to be more topical)
"The Worst Tool for the Job": if you need a tool, buy the cheapest one you can find. If it’s inadequate, or breaks, or you use it a lot, then buy the best one you can afford. If you follow this strategy, you’ll sometimes waste a little money by buying a cheap tool before buying a good one. But you won’t waste money buying expensive tools that you rarely use. And you won’t waste money by buying a sequence of incrementally better tools until you finally buy a good one.
Servant Leadership - Jason Malmstadt
Questionable Advice: “How can I drive change and influence teams... without power?” - Charity Majors
A few words on communication - Oskar Dudycz
Engineering Leadership Tactics: Finding Focus - Francisco Trindade
10 Best Innovation Frameworks - JD Meier
Biases and Fallacies Lead to Smol Thinking
Organizational Design
Building Organizational Resilience through Documentation and InnerSource Practices
Engineering Management
"A Simple Framework for Software Engineering Management": Responsibilities (people management, delivery leadership, technical system ownership) in a 2-axis grid with priorities (issues, things that are OK, ideas/aspirations). "To sum up, we can look at software engineering management as a combination of three areas of responsibilities: people management, delivery leadership, and technical system ownership. Paying attention to all three responsibilities is important. However the amount of attention each responsibility should get depends on the team, the organisation, the product, and other factors. It also changes over time. Within each responsibility area we can identify issues, things that are okay, as well as ideas and aspirations. Things that are already okay only need to be acknowledged. Issues need to be prioritised and promptly resolved. Ideas and aspirations should be evaluated and, if deemed relevant, executed or put on the roadmap."
"Engineering Management Checklist":
"This list isn't meant to be exhaustive, nor is every item listed here applicable all the time. It's meant to give a basic framework to help managers, particularly less experienced ones, think about balancing their responsibilities."
-
Section 1: Managing the team
- every member of the team knows what they should be working on
- every member of the team knows what to do if they finish a task, or get blocked
- every member of the team has had a meaningful career conversation within the last six months
- every member of the team receives timely, meaningful, actionable performance feedback
- work that needs to get done aligns with work that is rewarded by the promotion process
- performance reviews never contain surprises
- team members are able to express ideas for new projects or changes to the way the team works
- the team is able to give input on roadmaps and plans
- the team is staffed adequately and work is evenly distributed
- the team, overall, has the level of functional expertise required to do the work, and a reasonable number of stretch goals are available
- conflicts are resolved in a fair and respectful way
- diversity is represented and embraced; a broad spectrum of views are considered
-
Section 2: Managing peer relationships
- key team peer relationships are identified and regularly maintained through regular healthy, productive meetings, and effective written communication
- groups dependent on team's work can trust the commitments the team makes
- key peer teams have a clear idea of how they can request work to be prioritized by your team, with transparency into what the tradeoffs are
- team is able to get work required from dependency teams prioritized with a reasonable expectation that commitments are honored
- agreements are documented in writing
- progress and set backs are reguarly communicated to key stakeholders
- when collaborative projects are completed, credit is shared among the contributors
- there is a clear, mutually-respectful escalation path for issues that cannot be resolved between peer managers/engineers
- managers are able to discuss issues privately in a psychologically safe manner
-
Section 3: Managing senior mgmt relationships
- direct management has clear visibility into the progress of the team
- direct management/management chain is appropriately involved in issues requiring special attention
- you are able to advocate for specific prioritization decisions; priorities are set with transparency
- clear agreement on goals and definition of success
-
Section 4: Managing yourself
- Your own work-life boundaries are respected
- Your immediate and long-term career goals are documented in writing
- You are not stagnating, even if your immediate career goals don't involve a promotion
- impact is primarily expressed in achievements of the team and the growth of the team members
"Effective Technical Leadership": What makes a badass TL is broken down into three A's: attributes, activities and actions.
- Attributes: Over time, you should always be increasing three attributes: Knowledge, Speed, and Awareness.
-
Knowledge: If work is completed, but waiting to be reviewed, then you should almost always drop your own work and help move it forward.
- Speed: You should strive to be ultra-responsive and capable of making instant decisions, always kicking the ball forward.
- Awareness: You should be able to keep the current state of the entire project in your head at all times. Otherwise, you cannot be aware of potentially imminent blockers.
-
Activities: The two most important things that a tech lead can do also happen to be exact polar opposites: block and unblock.
- Block: The tech lead needs to be alert and aware to what is going on in the project, always ready to jump in and block bad decisions before they are made, typically armed with a better solution. Blocking should not stop progress, it course corrects so things can keep moving. Think harness, not safety net.
- Unblock: If someone has a question, you should be able to either give an answer or bring in the right person to field it.
- Redirect: Mentally build an expert index so you always know where to find an answer. Proactively adding the right individuals to any thread or code review can help increase the overall quality of the work.
- Decide: The faster you can reach a decision, the quicker others can act on it. When you do listen to your instincts, make sure that you're making a robust decision that can stand the test of time. When given a set of options, reduce the number to 2, see if there is a best choice based on experience or data. If not, redirect to someone better suited, or block the decision from being made or unblock it by going with your instinct.
- Show: Have the respect and trust of your team, which is best accomplished by demonstrating that you know your stuff.
-
Actions: There is a long assorted list. Here is an attempt to put its items into buckets:
- Management responsibilities "outward": Say "no" often to new or unnecessary features, vet the product's privacy and security concerns, work with other engineering teams especially on dependencies, etc.
- Management responsibilities "inward": Create and maintain launch and testing and release plans, shield engineers from management, setup team fix-its and hackathons and bug scrubs, escalate blocking issues as necessary, and load-balance work among the team, etc.
- Other management responsibilities: Help create and stack rank project priorities, create target milestone dates and correct and refine them as needed, etc.
- Best technical practices: Define best practices for issue tracking, maintain on-call and onduty processes, and ensure tests are being written for core functionality, etc.
- Team growth: Recruit engineers, review code in detail and give useful feedback, read and write and give feedback on design documents, help onboard, etc.
- Technical action: Identify technical debt, generate new ideas and elegant solutions, debug difficult production issues, write the right code at the right times, etc.
Why Executives Leave
What Team Structure is Right for DevOps to Flourish?
5 Tips for Being an Effective Tech Lead
- Learn to Delegate
-
When you take on the harder problems, it also misses an opportunities for other developers to grow and problem solve.
- For problems when your experience and knowledge are important, find a way to delegate but still be involved. Kicking off a design session to discuss general approaches, or reviewing progress a regular basis.
-
Find Time to Code
- Being involved in the code helps you build respect with the rest of the team, and keeps your knowledge up to date and current with constraints, problems, and the "shape" of the codebase.
-
Visualise Your Architecture
- Have a visual representation of their system architecture on-hand and uses it to have discussions with developers.
- Host a whole-team whiteboard session. Focus on attributes that drive your architectural vision (scalability, performance, usability concerns, etc) and how they have shaped your architecture. Call out assumptions and the historical context.
-
Spend Time 1-on-1 With Team Members
- Anything that you can do to make each person on your team better makes the overall team better.
- Understand the backgrounds, strengths, interests and goals of the team members. Align their tasks with their responses.
- Connect developers with opportunities for them to grow.
-
Learn to Speak the Language of the Business
- To communicate technical concepts to non-technical people, find the terms that business people use and find ways to explain tasks in those terms.
What It Takes to Be a Great Technical Lead
- Possess strong technical skills. You’re also responsible for fixing technical issues that your teammates can't solve. If you can't fix something yourself, find an acceptable workaround.
- Teach your teammates. If there are some core principles or practices that you want them to apply to their work, you must invest time to promote that understanding.
- Trust your teammates. If you trust a teammate, that developer will respond with improved output. The quality may not be ideal, but the developer will show more effort.
- Stimulate self-organization. Do not simply assign tasks to your teammates, but organize planning meetings where members can choose their tasks. But promote a balance in the assigned tasks.
- Don't keep the coolest technical tasks for yourself. Give your teammates the opportunities to work on such tasks. This raises morale, trust, and skill.
- Try to prevent overtime as much as possible. If in a situation where the team must put in some overtime, don't tell your teammates they have to do it; instead ask them if they want to do it. Also do not go home early while your teammates are still working.
- Remember that you are responsible for the final result. Never put the blame of something wrong on one of your teammates.
- Give credit where credit is due. Give credit where it is due, and make sure everyone else knows about it too, especially management. Never take credit for the work of a teammate.
- Realize that your teammates are not your developers. Having a leadership role does not mean that you can boss around your teammates. This destroys morale.
Looking at the team as a whole
"5 Things High-Performing Teams Do Differently"
- High-Performing Teams Are Not Afraid to Pick Up the Phone (communicate more frequently)
- High-Performing Teams Are More Strategic With Their Meetings (avoid poor meetings by requiring prework from participants; introduce an agenda; begin with a check-in that keeps team members apprised of one another's progress)
- High-Performing Teams Invest Time Bonding Over Non-Work Topics (high-performing team members are significantly more likely to spend time at the office discussing non-work matters with their colleagues (25% more) — topics that may extend to sports, books, and family)
- High-Performing Teams Give and Receive Appreciation More Frequently (within the best teams, appreciation doesn’t flow from the top down. It’s a cultural norm that’s observable in peer-to-peer interactions)
- High-Performing Teams Are More Authentic at Work (high-performing teams were significantly more likely to express positive emotions with their colleagues; interestingly, however, they were also more likely to express negative emotions at work. Why would expressing negative emotions at work yield more positive performance? It’s because the alternative to expressing negative emotions is suppressing them, and suppression is cognitively expensive. It involves expending valuable cognitive resources attempting to hide emotions from others, leaving less mental firepower for doing the work.)
What Google Learned From Its Quest to Build the Perfect Team (New York Times)
Leadership/You as the leader
"5 Things That Change When You Become a Leader" (HBR, Jan 18 2022):
* People don't work as much as you think:
-
"The Tyranny of The Plan"
-
A fractal of lies: Dr House was right: everybody lies. (More to the point, studies are often built off of interviews and interrogation, and people have a habit of telling interviewers not-entirely-truthful things for a variety of reasons.) "Whenever there is an advantage, or a power gradient, or a political agenda, or people just want to fuck with you for their own amusement, probably there are lies. And then people repeat those lies - sometimes purely innocently, sometimes adding their own lies on top."
-
What Google Learned From Its Quest to Build the Perfect Team (New York Times):
-
Meet is Murder (New York Times, 2016):
-
Is Blind Hiring the Best Hiring (New York Times, 2016):
-
Failure to Lunch (New York Times, 2016):
-
Managed by Q's 'Good Jobs' Gamble (New York Times, 2016):
-
Rethinking the Work-Life Equation (New York Times, 2016):
-
The Robots Are Coming for Wall Street (New York Times, 2016):
-
The Post-Cubicle Office and its Discontents (New York Times, 2016):
-
The New Dream Jobs (New York Times, 2016):
-
The myth of the flat start-up: Reconsidering the organizational structure of start-ups: "My study cautions against [the myth that start-ups should be flat], suggesting that adding a few hierarchical levels of mangers can substantially help start-ups achieve commercial success and survive in their hostile environments, albeit at a potentially marginal cost of creativity."
-
"Measuring an engineering organization"
-
"Developer Productivity at Google"; discusses the paper "What improves developer productivity at google? code quality"
-
"5 Things That Change When You Become a Leader" (HBR, Jan 18 2022):
- Your friends are no longer your friends. Effective leadership demands that you be even-handed in your treatment of every team member. The rule of thumb is to be friendly, not friends with your people.
- You have a duty of care. You used to be responsible only for your own behavior and performance; now that responsibility extends to every individual on the team. You have to ensure that your people have clear objectives; that their physical and mental well-being are safeguarded; that they're given clear feedback and strong direction.
- You're entrusted to manage resources. Managerial diligence demands that every decision you make optimizes the resources entrusted to you. This stewardship must take precedence over your own popularity, fear, and self-interest.
- You need to contribute more broadly. You're not only accountable for the outcomes of your own team, but also for contributing to the collective value that's delivered by the leadership team you're a part of. Great leaders seek to optimize the overall value delivered by the broader group, even at the expense of their own work.
- You must align yourself with the intent of senior management. As a leader, you don't have the luxury of being able to criticize the decisions made above you; you have to support the goals/objectives of the CEO and executive team. (Dissent but commit)
This leads to the 7 Imperatives of Great Leadership:
- Deliver value. Your job is to identify and communicate what value means in your context.
- Handle conflict. Adoping and embedding the mantra of respect before popularity is a crucial building block for leadership performance.
- Build resilience. Finding and overcoming adversity builds resilience so don't shy away from it--embrace it!
- Work at the right level. Your job is to teach--not do. It's critical that you adopt a mindset different than that of an IC. Your job is to ensure that the ICs on your team produce the best outcomes possible.
- Master ambiguity. Your job is to sit comfortably in ambiguity, and translate it into certainty for your people. As a frontline leader, your people should have unambiguous clarity on what they need to do to be successful. They will look to you for assurance, stability, and purpose--and if you want them to perform at their best, you need to give it to them. Doing so will require you to have a clear understanding of the org's long-term goals, how your individual work contribute to those goals, and the ability to distill and communicate that to your people.
- Make great decisions. The most successful companies make smarter decisions faster than their competitors; the earlier you can master smart decision-making, the better. It starts with knowing what makes a great decision, and then learning how to undertake the process with a sense of urgency. A checklist to determine the quality of your choices:
Great decisions:
- Are timely.
- Are made by a clearly accountable person.
- Are made as close to the required expertise as possible.
- Consider consultation from many different perspectives.
- Consider the holistic impacts of problems.
- Consider long- and short-term implications.
- Address the root cause of the problem (as opposed to just the exhibited symptoms).
- Are communicated appropriately.
-
Drive accountability. When accountability is shared or unclear, gaps and overlaps emerge. Be accountable for everything your team does, and hold each individual to account for what they need to deliver.
Know how your org works: "Social media, blog posts and conferences amplify aspirational ideas. There’s nothing wrong with this in my opinion — it’s important to constantly keep pushing the envelope further, after all. Your organization, however, rewards what you actually get done that benefits the organization, which might be a very far cry from whatever might be de rigueur on social media. ... One of the most effective things you can do to be successful at your job is to understand how your organization works. ... Managers need to deal with these skills as a part of their job description. So do ICs at the very senior levels, but it’s never too early to start cultivating this knowledge. In fact, a core part of mentoring engineers needs to be schooling them in how the organization works, which will then enable them to build a successful track record of getting things done. Shielding non-senior engineers from organizational politics not just stymies their growth but also hinders their visibility into the skills they’d eventually need to learn the hard way, skills for which there exists no easy playbook, even if some managers and senior ICs might take a more short-sighted view and see this as a way to help other engineers “maintain focus”. The most important skill for any engineer to posses is the ability to learn quickly.
- Understand Implicit Hierarchies: "Most organizations have a formal structure. This usually starts with a VP or a director at the top, down to individual teams. ... Most organizations ... also tend to have something of an informal structure, especially among the ICs. ... It’s important to be aware of this informal hierarchy, because as often as not, your work might end up being directly influenced by this hierarchy, irrespective of whatever your personal level and job title might be. ... Your efforts, as such, need to be multi-pronged:
-
Understand the implicit organizational hierarchy
- Identify the people who wield undue influence and their way of thinking and general philosophies (by either talking to them, or other people in the organization, or researching their past work, reading any articles or blog posts they might have written, or talks they might have presented, etc.)
- Identify how the aforementioned philosophies have been previously successfully applied to projects and teams they were on. Why were these efforts considered successful? What were the problems these philosophies solved, and what were the problems they didn’t solve (or exacerbated)?
- How do you build credibility with them? Can you lean on your past work? Your subject matter expertise? Your previous track record? Is there someone they trust and respect who can vouch for you, for them to take a leap of faith and agree to do things “your” way?
-
Cultures: Top-Down, Bottom-Up, and Both: Irrespective of titles and hierarchies, most organizations also have a somewhat top-down or bottom-up culture (or a mix of both). A top-down culture is one where the most important decisions are made from the top down. The person making the final decision could be either a tech lead, sometimes a manager, or a director level executive. On such teams, a large part of your success boils down to “managing up”. On bottom-up teams, the challenge is to manage laterally (in addition to managing-up).
-
Get comfortable with the "mess": You’re far likelier to encounter codebases that have “evolved” over time, with poor documentation, lots of outdated comments and often with little to no tests than you are to encounter ones which are perfectly documented, have well-tested public and internal APIs, and code which is perfectly obvious. You’re going to far more productive if you learn how to navigate such codebases successfully, which involves learning some of the following:
- how to gather just the right amount of information to get on with your task
- how not to get too caught up in the weeds unless required
- how to read a lot of code at a fast clip and come away with a reasonably good mental model of what it’s trying to do
- how to come up with hypothesis and use a variety of general purpose techniques and tools to validate the hypothesis
- how to reproduce bugs quickly without elaborate local configurations and setups
The same philosophy applies when working with sociotechnical systems like organizations: get comfortable with mess. You’re far likelier to encounter organizations comprising of teams and leaders of:
- varying levels of skill and ability to deliver on their promises
- varying (sometimes even opposing) incentives and reward structures
- varying appetites for risk or change
- varying philosophical views on software development and systems
- varying levels of tolerance for failure
- varying willingness to make investments (in people and projects) with a long-term view in mind
Being successful in such organizations requires quickly learning the topology of the organization and charting pathways to navigate it.
-
Look For Small (And Any) Wins: To build credibility, you need to demonstrate some degree of impact early on, instead of waiting for months to get a lie of the land before you start getting anything done.
-
Understand Org Constraints and Manage Your Expectations: It’s important to mention that individual managers (much less ICs), can sometimes do only so much when it comes to solving some of the more entrenched organizational problems.
You’re far more likelier to be one of those rare unicorn engineers who is a real force multiplier if you’re also:
- good at solving pressing problems
- relentlessly getting things done
- successfully creating change than just endlessly talking about the need to do so
Which, alas, requires understanding how your organization works."
Managing People: In short:
- As a manager, everything is your fault
* There is no point being angry at your team – ever
* You are in charge of processes and people
* And you got more information than they do, always
* You either created the processes where this outcome happened
* or you hired (or did not fire) the wrong people
* Ultimately everything is your fault
-
You manage processes; you lead people
- For some reason, "managing people" means for many that they need to control people's work.
- They end up micro-managing not only what when but also how people do their work.
- If you got the time to micro-manage people, you can most likely hire cheaper, less talented people for your work
- I think it roots in a misunderstanding of what the role of a manager is:
- your job is not to manage people
- but to manage processes and lead people
- You manage processes on how you expect work to be done, where each person's authority starts and ends, how their careers are made, and how all this can be discussed, and/or changed
- Additionally, you are leading people by example and through empathy.
- They have goals, fears and motivations. Frequently also problems outside of work.
- Act how you would want them to act if the role would be reversed.
-
Processes are expectations made explicit
- A lot of people make huge disclaimers around "processes."
- "We don't want too many processes" etc
- again, imho a misunderstanding
- Processes are not complex chains of people doing things that are burdened by horrible overheads
- Processes are expectations made explicit
- They can be as simple as "every morning we all do X to ensure everyone else is unblocked."
- Have few but very explicit processes and expect them to be followed
-
Decisions vs Opinions
- In every discussion/project/problem/situation, it needs to be clear who makes decisions
- everyone else only adds opinions.
- Ideally, the person who will afterward do (or lead) the follow-up work makes the decisions.
- Everyone else just adds opinions.
- This includes people of higher "rank" or pay.
- Their manager have a handbrake they can use to hard-stop decisions.
- Treat this as a literal handbrake.
- Imagine a car driving, and you need to pull the handbrake because the car needs to stop, but the driver doesn't react. Damage will follow.
- Pull the handbrake if absolutely needed and then discuss how to fix the situation.
- Hire based on good decision-making skills
- Fire based on poor decision-making skills
- Good decision-making skills include listening to other people's opinions.
- In case of doubt, see if you can trust the decision-maker by default.
-
Ownership
- It's hard to get people to own a problem space fully
- But this is the goal
- If they are the wrong person, you can still fire them
- Feedback them, help them
- Trust them and let them make mistakes (within damage barriers)
- Consider mistakes them leveling up
- The worst thing that can happen is that you frequently step in, and people disassociate from their work
- They become drones who do what's told instead of taking ownership.
- If this is your goal, you can hire cheaper, less talented people.
-
Avoid back and forth
- When defining processes, avoid back and forth
- Eg. if you give feedback on something assume that they will either do it or get back to you with reasons why not
- Don't expect them to get your approval
- Ain't nobody got time for that
-
Trust
- Always reflect if your nervousness is due to other people's work or your insecurity
- Should other people have to handle your emotions for you?
- Also, it's easy to trust when things go well
- The real challenge is when things go wrong
- Always differ between your frustration about a situation and your frustration about a person
- I am not saying "stay out of it"
- Stay in the loop, set expectations, voice opinions, but let them handle it. Use your handbrake if needed.
-
... through transparency
- The easiest way to have people trust your work is by transparently sharing it without request.
- Have everything accessible where people would look for it
- Don't make them ask for it, because most won't
-
... and is not binary
- We tend to think of trust as binary
- I either trust someone, or i don't
- But this isn't true
- You trust different people with different things differently over time.
- Think of trust as something that you systemize
- Eg what kind of trust do you give a new team member?
- What are they expected to do in the first weeks? first month?
-
Don't confuse autonomy and abandonment
- I frequently meet founders who hire people "and get out of their way"
- While this is principle correct it doesn't absolve you from enabling them to succeed
-
Decision Layering
- Different people in the company on various levels rely on each other on doing their work.
- A product manager can't do their job if the CEO doesn't know what their current priorities are.
- Don't load your work onto others in the company.
- And also avoid stepping into their work just because looks more fun.
-
Avoid drive-by management
- Don't start throwing your opinion or ideas around in meetings
- You most likely lack context, and most likely, you won't be the person needing to follow through.
- Make it clear that it's just opinions and not decisions.
- But know the power that the "opinion of the founder (or manager)" has towards most employees
- Use fyi tags in async communication that usually lacks the "nuance" of voice.
Btw, I call it drive-by management because the manager comes by a group of people having a discussion. They throw requests, change mandates, and ideas around like bullets, create confusion, panic, chaos, and when they leave, they leave a bloody mess behind.
-
Feedbacking people
- people x context = output
- I had great people in bad setups that had lousy output
- I had very ordinary people in great setups that churned out more work than a whole team
- When you feedback work, it's usually easier to discuss the context objectively than the person themselves
- What is the situation that led to current problems?
- What changed? What is currently required?
- A junior engineer not keeping up with the work?
- Is it their fault? Or is your team right now not able to support a junior learning the game?
- This is ok, but should be either fixed or acknowledged (by discontinuing)
- A huge production incident happened?
- How was this possible in the first place?
- Where was the focus of the engineering team?
- Was there a process in place to avoid it?
- Should there be one?
- The person breaking production isn't at fault here.
- A whole team focused on other priorities
- Was this for the right reasons? (eg release pressure?)
- Or the wrong ones? (lacking sophistication?)
- Always assume people you hired are motivated, and have the best intentions in mind
- And fire the ones that don't
-
Firing should never be a surprise
- People should never be surprised that they are fired
- Context changed, new requirements should have been communicated
- When you discontinue someone, you do it usually because of context
- The company changed
- The expectations of the role changed
- You realized you looked for the wrong hiring criteria
- It's most likely more your fault than theirs
- They might have hoped that their new efforts were enough
- But they will still understand when you fire them
-
Never delay firing
- Once you decide to fire someone, do it.
- Frequently people keep employees around in a zombie-like state
- "We should discontinue them."
- But you don't
- It's not for them
- They are most likely unhappy in their setup
- Not appreciated
- Not able to do good work
- You are most likely doing it for yourself
- Because you are not feeling good about firing someone
- They deserve better than you caring more about your feelings and future than theirs
- Set up a call and discontinue them
- Avoid any chitchat in the beginning
- Start directly with the topic and have explicit clarity on the next steps
- Make sure to communicate it as fact and truth
- Remember that in this moment it's not about your feelings or problems
- Then help them finding new roles
- In some countries firing someone is a matter of days in some months
- In either case manage that process pro-actively and with respect to the people who trusted you
- Those people trusted your team with their career
- Most likely the reason they are leaving not their fault but the changes in context
- Help them landing a new role that fits them
-
Explicit > Implicit
- Clear decisions after meetings
- No clear decision? Make that explicit too.
- Clear owners
- No clear owner? Make that explicit too.
- Hear everyone's opinions
- Make explicit who makes the decision
- And what the decision is
-
Best practices: Start by making true what's real
- When looking for best practices or changes in the team/processes, always look at first what already naturally emerged
- If you hire good people they usually start looking for solutions naturally
- Is this good? If yes make it explicit
- If not discuss changing it
-
Expect to refactor your company every few months
- Fast-growing startups have to refactor how they operate internally every 3-6 months
- So just go with the minimum changes you currently need
- There will never be a final endstate
- You will always be unhappy with processes in your company
- You will have growing pains until you stagnate
- Use the same principles you'd use in refactoring code
- Consider to
- Test in small isolation first
- Peer review
- Not to change everything at once
- Avoid over-engineering
- etc
-
Burnout
- It's a common misconception that burnouts come from hard work.
- Burnout comes from a felt loss of control and/or impact.
- Remember that you can burn out employees (or yourself) with little to no work.
- How can you give people control over their impact?
- How can you define boundaries around chaos around them?
-
Chaos is felt less by the people creating it
- A common frustration of founders is that their team can't keep up with pivots.
- As a founder, you most likely got more context on changes, you know earlier of them, and most importantly, you have control over them.
- Employees don't.
-
Expect more from managers that report from you
- By default, mistakes are not their team's fault but theirs
- Share your honest opinions on things with them privately
- By default, always give them the trust needed to make decisions
- They are accountable for the outcomes
- Responsible for all failures
- But not responsible for the success
- Success is the team's achievement
- They should also, whenever possible, give spotlights to their team instead of taking it for themselves
- The deal is simple: They get more authority; the team gets more ways to shine
Meetings
"The Remote Pop-In Meeting": "The pop-in, back before open floorplans, is when you physically walk into someone's office to ask them a question or spitball an idea. In an open floorplan you can instead swivel your chair or walk to their desk. The pop-in is valuable because it's as informal as email, but as high-bandwidth and low-latency as meetings. It's interruptive to be popped in on, but that interruption power is self-limiting: the effort of physically going somewhere is high, and the tools available to the target like doors, signs, and social cues are numerous and don't require much thought to implement. ... There's really no remote equivalent to the pop-in. There are products that help you "hang out" like Facebook Portal, but nothing that implements the pop-in. ... In our company Discord server, we give everyone one voice channel of their own. This is your "office". When you are online and able to be disturbed, you join your office, alone. You stay in there as long as you are "in". When someone wants to pop in, they join your voice channel. The chime plays, they say hello, you unmute and turn on video if you like, and have your pop-in. And that's really it."
Meet is Murder (New York Times, 2016)
"Making Better Meetings"
1:1s
Plucky 1:1 Starter Pack | Plucky 1:1 Manager Pack: "Conversation cards" for those awkward moments of silence in a 1:1. Highly recommended.
9 Questions for 1:1s (by Claire Lew, CEO of KnowYourCompany):
- "Are you afraid of anything at work?"
- "Have you seen something recently and thought to yourself 'I wish we'd done that'?"
- "Is there something we should measure in the company that we currently don't?"
- "Is there any part of the company you wish you were able to interact with more?"
- "Are there any benefits we don't offer that you'd like to see us offer?"
- "Is there an area outside your current role where you feel you could be contributing?"
- "Is there anyone at the company you wish you could apprentice under for a few weeks?"
- "Have you seen someone here do great work that's gone unnoticed?"
- "Are there things you don't know about the company that you feel you should know?"
Ashlee Clifton's (Rocket Mortgage) Guide to 1:1s
-
My personal Beliefs and expectations that carry into work - These are your personal ISMs. List your beliefs and expectations so it is clear for your team members what you expect.
-
My personal and work fears - List here what is always in the back of your mind. Show them you are vulnerable you are not all sunshine and rainbows.
-
Best Ways I learn - Let them know how you like to learn, receive feedback, etc. This will help open the lines of communication and get you started on the right page.
-
I am motivated by (Goals, Praise) - Let the person know what motivates you, so they can help. How do you like to receive recognition?
Organizational structure
"The myth of the flat start-up: Reconsidering the organizational structure of start-ups": "My study cautions against [the myth that start-ups should be flat], suggesting that adding a few hierarchical levels of mangers can substantially help start-ups achieve commercial success and survive in their hostile environments, albeit at a potentially marginal cost of creativity."
Interviewing/Hiring
"Are Emily and Greg More Employable than Lakisha and Jamal? A Field Experiment on Labor Market Discrimination": "We perform a field experiment to measure racial discrimination in the labor market. We respond with fictitious resumes to help-wanted ads in Boston and Chicago newspapers. To manipulate perception of race, each resume is assigned either a very African American sounding name or a very White sounding name. The results show significant discrimination against African-American names: White names receive 50 percent more callbacks for interviews. We also find that race affects the benefits of a better resume. For White names, a higher quality resume elicits 30 percent more callbacks whereas for African Americans, it elicits a far smaller increase. Applicants living in better neighborhoods receive more callbacks but, interestingly, this effect does not differ by race. The amount of discrimination is uniform across occupations and industries. Federal contractors and employers who list Equal Opportunity Employer' in their ad discriminate as much as other employers. We find little evidence that our results are driven by employers inferring something other than race, such as social class, from the names. These results suggest that racial discrimination is still a prominent feature of the labor market."
"Does Stress Impact Technical Interviews?": "Software engineering candidates commonly participate in whiteboard technical interviews as part of a hiring assessment. During these sessions, candidates write code while thinking-aloud as they work towards a solution, under the watchful eye of an interviewer. While technical interviews should allow for an unbiased and inclusive assessment of problem-solving ability, surprisingly, another possibility is that technical interviews are instead a procedure for identifying candidates who best handle and migrate stress solely caused by being examined by an interviewer (performance anxiety). To understand if coding interviews—as administered today—can induce stress that significantly hinders performance, we conducted a randomized controlled trial with 48 Computer Science students, comparing them in private and public whiteboard settings. We found that performance is reduced by more than half, by simply being watched by an interviewer. We also observed that stress and cognitive load were significantly higher in a traditional technical interview when compared with our private interview. Consequently, interviewers may be filtering out qualified candidates by confounding assessment of problem-solving ability with unnecessary stress. We propose interview modifications to make problem-solving assessment more equitable and inclusive, such as through private focus sessions and retrospective think-aloud, allowing companies to hire from a larger and diverse pool of talent."
Is Blind Hiring the Best Hiring (New York Times, 2016)
Meta/People
T-Shaped People and Academia: "... academia is doing a disservice to ‘T-shaped persons,’ i.e. persons combining deep expertise in one or more fields with an ability to collaborate across areas. T-shaped persons are often contrasted with I-shaped persons, commonly known as experts. Given the state of the art in the software industry, T-shaped people are a sought-for commodity: the current ‘framework du jour’ might be obsolete in a few years, but the horizontal bar of a T-shaped person ensures that they can also contribute to other aspects of a project, and quite likely will develop new vertical bars, i.e. new expertise over time."
People don't work as much as you think
A fractal of lies: Dr House was right: everybody lies. (More to the point, studies are often built off of interviews and interrogation, and people have a habit of telling interviewers not-entirely-truthful things for a variety of reasons.) "Whenever there is an advantage, or a power gradient, or a political agenda, or people just want to fuck with you for their own amusement, probably there are lies. And then people repeat those lies - sometimes purely innocently, sometimes adding their own lies on top."
Rethinking the Work-Life Equation (New York Times, 2016)
The Robots Are Coming for Wall Street (New York Times, 2016)
The Post-Cubicle Office and its Discontents (New York Times, 2016)
The New Dream Jobs (New York Times, 2016)
Trouble in programmer’s paradise: gender-biases in sharing and recognising technical knowledge on Stack Overflow: "This paper examines gender-biases on Stack Overflow, the world’s largest question-and-answer forum of programming knowledge. Employing a non-binary gender identification built on usernames, I investigate the role of gender in shaping users’ experience in technical forums. The analysis encompasses 11-years of activity, across levels of expertise, language, and specialism, to assess if Stack Overflow is really a paradise for programmers. I first examine individual users, asking if there are gender differences in key user metrics of success, focusing on reputation points, user tenure, and level of activity. Second, I test if there are gender-biases in how technical knowledge is recognised in the question-answer format of the platform. Third, using social network analysis I investigate if interaction on Stack Overflow is organised by gender. Results show that sharing and recognising technical knowledge is dictated by users’ gender, even when it is operationalised beyond a binary. I find that feminine users receive lower scores for their answers, despite exhibiting higher effort in their contributions. I also show that interaction on Stack Overflow is organised by gender. Specifically, that feminine users preferentially interact with other feminine users. The findings emphasise the central role of gender in shaping interaction in technical spaces, a necessity for participation in the masculine-dominated forum. I conclude the study with recommendations for inclusivity in online forums."
Articles
-
Failure to Lunch (New York Times, 2016)
-
Managed by Q's 'Good Jobs' Gamble (New York Times, 2016)
-
Twitter thread: "Here are 12 things your manager may not be telling you, but I know for a fact will help you.":
- As a software engineer, you are not there to take requirements blindly. You are there to partner with your business and product partners. That means you have to earn an equal seat at the table on product decisions.
- Being smart or good at what you do does not give you the right to be a jerk. Empathy as an engineer is a superpower. Caring about those you work with will do more for your career than writing beautiful defect-free code.
- As someone in the code, every day, you will see things that others will never see. You will know what's possible; they'll guess what's possible. Some of the best product features are born because engineers found clever ways to solve something. Look out for those things.
- You are there to add value first. All the code you wrote will end up in the recycling bin of some computer if it does not add value directly or indirectly to the business. It doesn't matter how pretty your code is or how much you love it if it doesn't add value.
- Your code should follow this pattern:
- Make it work
- Make it fast
- Make it beautiful
Reminder: You won't have a chance to make it fast or beautiful if it doesn't add value.
- Build relationships with engineers in other teams and other companies. Learn about the problems they are solving. Learn different architecture and designs than the ones your team uses. You never know when their solutions will save you days of work.
- You don't need permission to add value. If you see something and know you can fix or improve it, do it. Nobody will ever say to you, "why did you add all that value? WTF is wrong with you!?" Every time I've done that unexpectedly, I've earned outsized rewards.
- 10x engineers do exist and so do .1x engineers too. If you think they don’t exist, that’s just because you haven’t worked with any of them yet. (I disagree with this one immensely, and I despise the "that's just because you haven't worked with one yet" coda that essentially tries to abort any disagreement ahead of time.)
- Just because you think someone shouldn’t be hired, that does not mean they aren’t a good engineer. It also does not mean they don’t have a strong work ethic. A strong work ethic is the most important thing, and it's nearly impossible to tease out in an interview.
- Advocate for junior engineers. My friend @VicVijayakumar reminded me that just because they don't have 10+ years of experience does not mean they won't be good. Without junior engineers on the team, no one will grow. Help others grow; you'll grow too.
- Have empathy for the people you interview. You could be in that situation. The set of things to know is large, even if you only ask basics. Plus, on a whiteboard, the other person is being judged. They have a lot to lose, maybe hundreds of thousands in income.
- Even though you work with computers, your career and future depend on people. Until AI runs things, people still run the world, and relationships matter a lot. Build relationships with people outside of engineering, listen to their problems. It will change your trajectory. (AI won't run things; or, arguably, computers are already running things. It won't change much aside from scope and a gently-increasing distance from the manufacturing cycle. But humans will never give up some level of control, we're too egotistical for that.)
Detail Pages:
- 11 Promises From a Manager: Threads Twitter threads of "11 promises"
- Art of the Start Startup bible for many folks.
- Behind Closed Doors The Secrets of Great Leadership.
- Crucial Conversations How to have important emotional conversations with people (when opinions vary, stakes are high, and emotions run strong).
- CTO Links Curated and opinionated collection of resources around CTO/VP-ness.
- Cynefin A framework for making decisions.
- Death by Meeting Running effective meetings.
- Diataxis A way of thinking about and doing (organizing) documentation.
- Elegant Puzzle Systems of engineering management.
- Essays on People A collection of essays on people.
- Essential Drucker Selections from the management works of Peter F Drucker
- Feedback Fallacy "Radical candor" feedback doesn't actually work; instead, prefer to accentuate what the individual already does well and build on that.
- Good Strategy Bad Strategy A book on how to differentiate good strategy from bad strategy.
- Google re:Work Guides Practices, research, and tools from Google to improve your people processes.
- HBR's 10 Must Reads 2021 Notes from the book.
- HBR's 10 Must Reads for New Managers Notes from the book.
- HBR's 10 Must Reads on Building a Great Culture Notes from the book.
- HBR's 10 Must Reads on Diversity Notes from the book.
- HBR's 10 Must Reads on Entrepreneurship Notes from the book.
- HBR's 10 Must Reads on Leadership Notes from the book.
- HBR's 10 Must Reads on Managing People Notes from the book.
- HBR's 10 Must Reads on Managing Yourself Notes from the book.
- HBR's 10 Must Reads on Mental Toughness Notes from the book.
- HBR's 10 Must Reads on Platforms and Ecosystems Notes from the book.
- HBR's 10 Must Reads on Strategy Notes from the book.
- HBR's 10 Must Reads on Strategy, Vol 2 Notes from the book.
- HBR's Everyday Emotional Intelligence Notes from the book.
- HBR's Guide to Making Every Meeting Matter HBR's collection of essays on holding productive/useful meetings.
- HBR's Guide to Office Politics Notes from the book.
- HBR's Guide to Performance Management HBR's collection of essays on performance management.
- HBR Manager's Handbook Notes from the book.
- Hunting Tech Debt via Org Charts "As I talk other people through their legacy modernization struggles, the first piece of advice I give them is to look at the org chart."
- Influence: The Psychology of Persuasion Notes from and about the book.
- Interviewing Collection of links and ideas around tech intervews.
- It's Your Ship! "Management techniques from the best damn ship in the Navy." Destroyer captain's story of management principles learned from command.
- jrnl A command-line tool for journaling work activities on a device.
- Leading Change How to not fail at digital transformation efforts.
- Liberating Structures Simple Rules to Unleash a Culture of Innovation
- Management and Admins Reading Thoughts, notes, and links on how to work with admins
- Management frameworks A collection of leadership/management frameworks/scaffolding, for thinking about how to frame steps and thinking.
- Manager Pool Collection of management patterns.
- Managing Humans Managing technical teams of people.
- Managing Oneself Most of us have to learn to manage and develop ourselves, which also means know how and when to change the work we do.
- Marketing Myopia The reason growth is threatened, slowed, stopped is not because the market is saturated; it is because there has been a failure of management.
- Meeting Design Notes from the book.
- Mission-Critical Meetings Notes from the book.
- Multipliers How the best leaders make everyone smarter.
- Product Roadmaps Developing product roadmaps.
- Remote: Office Not Required DHH's screed on remote work. Most of it is now (2021) more widely-accepted as a given, but still useful as a reference.
- Remote management Topics and links around remote management of teams.
- Rework DHH's book on business (and, to a much lesser degree, management).
- Silos, Politics, and Turf Wars How to eliminate silos in organizations.
- Simple Rules Descriptions of how to guide behavior using simple rules.
- Software development roles A collection of links and notes on the different roles that can/do appear in software dev teams.
- Staff Engineer: Leadership Beyond the Management Track Not everyone needs to be the boss.
- Steve Yegge Rants Some links/excerpts from Yegge's various rants.
- Superbosses A study of what makes 'superbosses'--those bosses who create a large 'coaching tree' of excellent managers--tick.
- Surprising Science of Meetings Notes from the book.
- Sway The irresistable pull of irrational behavior
- Switch How to Change Things When Change Is Hard
- Team Topologies Organizing business and technology teams for fast flow.
- Technology Fallacy How people are the real key to digital transformation
- The Advantage (Placeholder)
- The Coaching Habit Say Less, Ask More & Change the Way You Lead Forever
- The Eleven Laws of Showrunning A showrunner's manifesto about being an executive producer on a TV show.
- The Field Guide to Understanding 'Human Error' (3rd Ed) A new view of accidents caused by 'human error'.
- The Five Dysfunctions of a Team Understanding teamwork and overcoming the common dysfunctions of a team.
- The Five Temptations of a CEO Five ways CEOs go wrong and how to avoid them.
- The Four Obsessions of an Extraordinary Executive (Placeholder)
- The Ideal Team Player What makes for the ideal hire on your team?
- The Motive (Placeholder)
- Thinking Fast and Slow System 1 and System 2 types of thinking and how to move from one to another.
- Thinking in Bets How to make decisions with less than perfect information.
- Turn the Ship Around! "A true story of turning followers into leaders." Management principles from a submarine captain.
- Why Motivating People Doesn't Work (and What Does) The New Science of Leading, Energizing, and Engaging
- Working Backwards An insider look at Amazon's internal practices and philosophies.
Last modified 02 October 2024