"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."
"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."
"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.)
"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."
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."
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."
"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:
- 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.
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."
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.
- 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
- 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
- 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.
- 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
- 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
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.)
These are some notes from insightful blog posts on what it takes to be an effective tech lead.
What makes a badass TL is broken down into three A's: attributes, activities and actions.
Over time, you should always be increasing three attributes: Knowledge, Speed, and Awareness.
The two most important things that a tech lead can do also happen to be exact polar opposites: block and unblock.
There is a long assorted list. Here is an attempt to put its items into buckets:
"The 1-on-1 Toolkit is my mission control for managing my teams; it's where we define actionable goals that are tied to specific sections of the career ladder, track progress towards each goal, set 1:1 agendas so that time is well-spent and focused on clear objectives, and capture kudos—all in one place.