For the longest time, I’ve been looking for a lightweight but meaningful way to gauge how my team is doing when it comes to execution. Over the years, I’ve tried many approaches, but one framework has stuck with me because of how much signal it gives for how a team is really operating. I was introduced to this framework at Marqeta by Kim Stroeger (thanks, Kim!) and I have been using it ever since.

The metrics

Every sprint, I track three simple metrics for my team:

Say/Do

This one’s about reliability. It’s the ratio of the number of tasks completed in the sprint to the number of tasks the team committed to when planning it.

Say/Do = (# of committed tasks completed) / (# of committed tasks at sprint start)

For example, if we start a sprint with 10 committed tasks and complete 6 of them, our Say/Do is 60%. A high Say/Do over time usually means the team understands its capacity well and follows through on its commitments. A low Say/Do can flag problems with estimation, unexpected churn, or unclear priorities.

Churn

Churn measures how much the plan changes after the sprint starts. If we added 2 tasks mid-sprint and removed 1 from the original plan of 10, our churn would be 30%.

Churn = ( (# of tasks added after sprint start) + (# of tasks removed after sprint start) ) / (# of committed tasks at sprint start)

Churn helps assess how stable the sprint plan was. If it’s consistently high, that might mean we’re discovering too much work after we start, or our sprint planning isn’t sufficiently informed.

Total Done

This one’s all about capacity understanding. It looks at the total work completed in the sprint — original tasks plus any added — relative to the original sprint plan.

Total Done = (# of tasks completed***) / (# of committed tasks at sprint start)

*** includes tasks that were originally committed at sprint start and those added after

If we start with 10 tasks, add 5, remove 1, and finish all 14, our total done is 140%. That might look great, but if it happens all the time, it could point to sandbagging or chronic under-commitment.

Tracking and Usage

I’ve written a small Google Apps Script that computes these metrics automatically based on our JIRA data (I’ll share that in a future post). But honestly, you can just as easily calculate these by looking at your sprint report in JIRA and doing the math by hand or in a spreadsheet.

These metrics aren’t something I share with upper leadership. Not because they aren’t useful, but because numbers like these can be misused. It’s tempting to reduce a team’s performance to a percentage, and that’s almost always misleading.

Instead, I use them for:

• Team retrospectives, to spark reflection.
• My own sense of team health, so I can look for signs of overload, uncertainty, or process dysfunction.

What they have revealed

Here are some real patterns I’ve seen:

• Low Say/Do + High Churn: We’re committing to one thing and then getting pulled in other directions. Usually a signal that product owners and scrum masters need to prep better or that the team is in a reactive mode (like IT support). In the latter case, I’ve even recommended switching from Scrum to Kanban.
• Low Say/Do + Low Churn: Our scope/capacity estimates are off. This is fixable with better estimation and planning.
• High Total Done (>100%) regularly: We might be sandbagging — either under-committing or inflating estimates. Seen this more than once.

A pinch of salt…

If you’re an engineering manager or a scrum master, I encourage you to try tracking these and, more importantly, share the data with your team. Done right, this kind of reflection can massively improve how responsibly and confidently a team commits to work.

But, please don’t make these mistakes:

1. Don’t use numbers to judge: These metrics start conversations. They don’t tell the full story. I’ve seen teams with perfect Say/Do ratios that were gaming the system by hiding work on secret JIRA boards or backlogs. And I’ve seen teams with “bad” metrics absolutely crushing critical customer deliverables. Context matters more than percentages.

2. Look for patterns, not one-offs: A low sprint Say/Do once? Probably fine. Three times in a row with a corresponding trend in churn? That’s something to dig into.

3. Don’t let metrics override agility: It’s okay to change course mid-sprint if something high-impact comes up. Don’t reject that just to protect your churn number. The point of scrum is being agile, not being rigidly predictable.

These metrics are easy to track, simple to understand, and incredibly powerful when used with care. Just remember: they’re a mirror, not a scoreboard. Use them to see what’s really going on and to help your team get better every sprint.

When a senior software engineer joins a new company, there’s often an unspoken expectation, sometimes even a belief, that they will hit the ground running, level up the team, and become an influential voice from day one.

But in reality, many senior engineers end up torpedoing their own success within the first few months.

Despite having deep experience and strong resumes, some struggle to adapt to their new environment. They unintentionally alienate their teammates, push ideas that don’t land, or adopt a work style that doesn’t fit the culture. And by the time the damage becomes visible, their long-term trajectory may already be off course.

After watching this play out a few too many times, I’ve started recognizing a few common missteps that tend to sink reputations before they’ve had a chance to rise.

Mistake 1: Expecting influence without earning trust

At their previous companies, these engineers were trusted voices. Their suggestions carried weight. Their designs shaped systems. Their decisions often set direction.

But when they join a new team, none of that past trust comes with them. And yet, some act as if it should.

They challenge decisions without fully understanding the context behind them. They’re surprised when a junior engineer pushes back. In 1:1s, they vent about “not being accepted by the team” or “being met with resistance”. Meanwhile, existing team members quietly share their own frustrations: “They don’t understand how things work here!” or “They’re pushing ideas without really listening”.

At the heart of it is a simple disconnect: influence isn’t granted. It’s earned. And trust takes time. The senior engineers who succeed are the ones who listen first, ask questions, and show respect for the team's context before offering their own perspective.

Mistake 2: Copy-pasting solutions from past lives

Another common misstep is trying to replicate technical patterns from previous jobs, without asking whether they make sense in this new context.

I once worked with a senior engineer who had come from one of the FAANG companies. Early on, they proposed restructuring part of our Spring Boot app to make it more extensible for hypothetical use cases. While the design wasn’t inherently flawed, it introduced a lot of abstraction and complexity, for needs we weren’t even sure we had.

It’s a classic example of prematurely optimizing for scale or flexibility because “that’s how we did it at ABC”. But what works at a 10,000 person company doesn’t always work at a 50 person one. B2B vs. B2C, early-stage vs. mature platform — all of those differences matter.

A telltale sign is when suggestions begin with:

“At my PREVIOUSCOMPANY, we used to …”_

That phrase alone isn’t persuasive. And if not backed by a thoughtful discussion of tradeoffs, it can quickly start to erode credibility.

Mistake 3: Clinging to old work habits

Sometimes the problem isn’t technical — it’s behavioral.

In large companies, senior engineers often operate in narrower lanes. Architects may spend their time designing systems, not necessarily writing production code. On-call may be managed by a separate escalations or support team.

But smaller companies, startups, or mission-oriented teams are different. Everyone codes. Everyone debugs. Everyone joins the on-call rotation. And participation in the culture is part of building trust.

I’ve seen senior engineers show up, stay passive during incidents, and skip fun team rituals, all while acting like their heads are down on “real work.” But what their teammates see is someone who isn’t showing up for the team. Over time, this creates distance and that distance becomes career-limiting.

What should managers do?

As engineering managers, we’re often the first to spot the signs: mounting friction in meetings, rants about the new teammates in 1:1s.

The instinct is often to step back and let things settle. But early intervention. done with care, can make all the difference.

Here’s what I’ve found helpful:

• Set expectations explicitly. Don’t assume a senior engineer will automatically grasp what “being hands-on” means at your company. Be clear about expectations — from contributing to the codebase to engaging in the team culture.
• Talk about these anti-patterns openly. Don’t tiptoe around it. It’s often helpful to have a candid conversation during onboarding about common traps that senior engineers fall into when switching jobs. Most appreciate the clarity. I have an explicit principle that I lay out for senior engineers in one of our initial 1:1s after they join — “The responsibility of adapting falls on the senior-most person in the situation”. Whether it’s a meeting, a team, or a new org, seniority isn’t about being the loudest voice in the room. It’s about being the one who reads the room, adapts their style, and leads by example.
• Facilitate trust-building, not just onboarding. Intros and documents are not enough. Pair the new engineers up on projects with existing team members. Encourage collaboration. Help them earn credibility through shared work.
• Coach them on business and cultural context. Especially when engineers come from different industries or company stages, help them understand what’s different here. Business models shape engineering tradeoffs. Show them that lens.
• Identify a “first win”. One of the best tools you have as a manager is shaping a 30-60-90 day plan that includes an early, achievable win. This gives the new hire momentum, helps them build trust quickly, and boosts their own sense of belonging.
• Mediate early when there’s friction. If you’re hearing mismatched perspectives in your 1:1s, don’t ignore them. Get both sides talking — directly to each other. Translate intentions. Often, both parties are acting in good faith but speaking past each other.

It’s interesting to see that none of these missteps come from a place of bad intent. In fact, they usually come from a desire to help. But the habits and instincts that served someone well in their previous role don’t always carry over.

The most successful senior engineers I’ve worked with are the ones who treat a new job not as a continuation of their last one, but as a clean slate. They join a new team with an eagerness to learn and contribute, rather than question and judge.

No matter how much experience you bring to the table, a new role is a reputation reset and how you handle that reset makes all the difference.

There’s a lot of advice out there about how to make a great first impression. But not enough people talk about the last impression. How you leave a team or a company can often define how you’re remembered, far more than you think.

When engineers are on their way out, whether it's for a better opportunity or just time for a change, there's a temptation to mentally check out. “I’m done here” they think. But your reputation doesn’t stop the day you resign. In fact, the way you handle those last few days or weeks can either seal the good reputation you’ve built, or destroy it in a flash.

A while back, an engineer reporting to me gave notice. Totally fair. People move on. But from the moment they resigned, they switched off. No-shows in daily standups. Hours to respond to Slack messages, if at all. The rest of the team picked up the slack while they coasted, thinking no one would notice. People did notice. What could’ve been a respected send-off turned into a silent goodbye, and a reputation that took a hit.

Now, contrast that with something from my own journey. Back in 2005, I was wrapping up my time at Philips Semiconductors in Bangalore. Three days before my last day, I was up till 1 AM in the lab, determined to fix a tricky bug in the MOV file decoder I had been working on for the past several days. I wasn’t chasing praise or some final reward. I just wanted to hand off something complete and solid. The next day, I passed it along proudly to my teammate. To this day, that’s one of my proudest exits.

Break your reputation or leave like a pro!

If you’re ever thinking of leaving, here’s what not to do if you care about the name you leave behind:

• Slacking Off: Disengaging, missing meetings, being hard to reach.
• Negative Talk: Complaining about the team, product, or leadership on your way out.
• Withholding Knowledge: Leaving gaps in documentation, not sharing important context.

These behaviors not only make life harder for your team, but they can also follow you. Tech is a small world, you never know when you’ll cross paths with former teammates again.

Now, here’s how to leave with your head high:

• Stay Engaged: Show up, contribute, help the team move forward, even if you're leaving.
• Help Out: Offer to assist in the transition, answer questions, and support your teammates.
• Document Thoroughly: Write down everything someone will need to pick up where you left off.
• Be Professional: Keep your tone positive, avoid gossip, and end on a respectful note.

Leaving gracefully isn’t just about your current team. It’s about the reputation that follows you to your next role.

If you’re a manager who’s moving on, the stakes are even higher. You’re not just handing off your own work, you’re responsible for setting your team up for success after you’re gone.

Here are a few things you must consider:

• Prioritize Your Team’s Future: Try to complete or at least contribute to performance reviews for your direct reports before you leave. It’s a small effort that shows big care.
• Leave a Strong Context Trail: Thoroughly document ongoing initiatives, challenges, team dynamics, and key technical or strategic decisions. Your replacement will thank you.
• Don’t Rush the Exit: Give plenty of time for the handoff. A thoughtful, deliberate transition makes your departure feel like a professional move, not an escape.

How you exit as a manager reflects not just on you, but on your leadership style. Take the time to close out your chapter with care.

I’ve seen both kinds of exits as a manager, and I can tell you, those who leave like professionals are remembered fondly. Their contributions live on, and they’re the ones I’d gladly work with again in the future. Those who burn bridges? Well, it’s hard to forget those, too.

Your last impression might just be the one people remember the most. Make it count.

Today, I want to talk about a silent killer of software engineer reputations — bad coding hygiene.

I’ve seen it happen over and over again. A new engineer joins the team, eager to start strong. They dive into the code, push a few commits, open their first pull request… and then it hits. Reviewers look at the code and find a mess: test cases that don’t follow naming conventions, i and j used as variable names, dead code hanging around like forgotten leftovers, unformatted blocks of logic, and the classic — TODOs that scream “I didn’t finish this but please merge anyway.”

Now here’s the thing: none of these issues are rocket science. They’re not even “hard” problems. These are the little things. The basics. And yet, they leave a big impression. Not a good one.

Why does this happen?

Sometimes it’s because the engineer came from a place where no one cared (surprisingly I have observed a pattern here — early stage startups where founders over emphasized “moving fast”). They weren’t used to teams that hold high bars, so they think these “little things” are just unnecessary ceremony.

Other times, they just don’t bother reading the docs or understanding the conventions already in place. They get their task, write code in a vacuum, and call it a day — not realizing that the team sees more than just functionality. They see craft.

And then there are the “I only care about my task” types. These engineers slap their changes into the codebase with zero awareness of what’s around them. Their PRs not only break hygiene — they break cohesion. And if you look deeper, their work often shows bigger problems: poor design choices, fragile abstractions, and code that doesn't feel like it belongs.

And finally, some folks just think, “That’s what reviewers are for, right?” Nope. Reviewers aren’t your personal quality assurance team. They’re collaborators, not cleanup crew.

How does the team respond?

On healthy teams, this kind of behavior gets flagged right away. It comes up in PR comments, in 1:1s, maybe even escalates if needed. And that’s a good thing — teams that care about quality should hold the bar.

But on teams where management is distracted, overly political, or simply doesn’t want to rock the boat? It gets brushed aside. That’s when the rot sets in. Quality slips. Trust erodes. Morale drops. And soon, the team starts normalizing mediocrity.

Why it matters

If you’re a new engineer, here’s the real talk: **you are building your personal brand from day one **(HT to Adan Amarillas who introduced me to this concept of an engineer’s personal brand). Your teammates are watching — not because they’re judging, but because they’re learning whether they can count on you. Can they trust your code? Will you leave things better than you found them? Do you care?

If your first impression is “I don’t bother with the basics,” then don’t be surprised when you don’t get the meaty projects, or when feedback about your work is lukewarm. You’re not just writing code — you’re telling your team how seriously you take your craft.

And if you’re a manager, here’s your part: don’t ignore this. If someone’s not willing to do the little things right, why would you trust them with the big things? Protecting them, excusing them, or just staying silent doesn’t help them — and it definitely doesn’t help your team.

Clean code isn’t about perfection. It’s about respect — for the craft, the team, and the product. And it’s one of the easiest ways to show that you give a damn.

Ultimately, you are what you ship.

When I take on managing a new engineering team, whether by inheriting an existing one or hiring from scratch, one of the first things I do is create a Team Knowledge Density document. This document helps me understand how knowledge is distributed across the team, identify areas where expertise is siloed, and take action to mitigate risks. Over the years, it has proven to be one of my most effective tools for setting up teams for success.

Why I Created This Document

I started using this approach after a key engineer left one of my teams shortly after I joined. Their departure left behind a knowledge gap that was difficult to identify and address in real time. Since then, I’ve made it a practice to proactively map out the team’s knowledge areas early on, so that I can take action before such gaps become critical issues.

What the Document Captures

The Team Knowledge Density document is a structured record of:

1. Key knowledge areas in the team’s primary domain that the team needs to deliver.

2. Individual knowledge levels in each area, categorized as:

   • Newcomer – No prior experience in the area
   • Competent – Some familiarity but needs support for larger tasks
   • Expert – Deep knowledge, capable of handling tasks independently and strategically

3. Connected domains – Areas owned by other teams but important for cross-team collaboration (e.g., APIs, services, or dependencies that the team relies on)

This document is typically maintained as a shared table where each row represents a knowledge area, and each engineer self-assesses their proficiency level.

An Example: The Knowledge Density Document in Action

To illustrate, let’s consider a hypothetical Payments Engineering Team responsible for payment processing, fraud detection, and transaction reconciliation.

Primary Knowledge Areas

Connected Knowledge Areas

Looking at the example above, a few key insights stand out:

1. Knowledge Silos – Alice is the only expert in Payment Gateway integration and Refund & Dispute Handling. This presents a risk—if Alice is unavailable, the team may struggle to maintain these critical systems.

2. Gaps in Connected Domains – Bank Compliance is a key area that the team interacts with, yet multiple engineers are newcomers in this space. This could slow down work that interfaces with this area.

3. Opportunities for Knowledge Sharing – Diana has expert knowledge in ledger reconciliation. This is a great opportunity for them to mentor others and spread knowledge in this space.

With this information, I can now take action to close these gaps.

How I Build and Maintain This Document

1. Interviewing Engineers – When I join a new team, I first interview engineers to identify key knowledge areas based on the team’s charter.

2. Self-Assessments – Each engineer assesses their knowledge level for these areas.

3. Quarterly Updates – I revisit the document every quarter, updating it based on my observations and validating changes in 1:1s.

Once the document is in place, it becomes an actionable tool rather than just a static reference. I use it to:

• Close Knowledge Silos – If only one person is an expert in a critical area, I find opportunities for others to work on projects in that space or arrange knowledge-sharing sessions.
• Create Development Goals – New team members can use this document to identify areas to ramp up on.
• Advocate for Team Growth – In one case, the document revealed that the team was responsible for too many knowledge areas, helping me make a case for additional headcount and splitting the team into two.
• Prioritize Learning Investments – When I discovered that no one on the team had expertise in certain parts of the codebase, I used this document to align with my product counterpart and carve out roadmap time for engineers to learn and build knowledge.

A document like this requires careful communication. I always clarify upfront that this is not a performance review tool — it’s a way to help the team succeed, which in turn supports each individual’s success. I also keep the document public within the team, so engineers know who to reach out to when they need help on specific topics, especially in urgent situations.

If you want to do this in your team…

If you want to implement a similar approach for your team, here’s what I recommend:

1. Involve the team in building it – Let engineers contribute to defining knowledge areas and self-assessing their expertise.

2. Frame it as a tool for team success – Set clear expectations that this is not a performance evaluation, but rather a way to identify opportunities for growth and reduce risk.

3. Use it to drive meaningful action – Don’t just create the document — use it to plan knowledge sharing, advocate for team resources, and ensure resilience in critical areas.

By consistently using this document, I’ve been able to proactively strengthen teams, improve collaboration, and create a more resilient engineering organization. I hope this tool helps you achieve the same for your teams!

In my engineering team, we hold daily standups, and to keep things engaging, we wanted to randomize the order of speakers each day. However, we quickly realized that while randomizing keeps things fresh, it also catches people off guard if they don't know when they will be called upon. To solve this, I built an automation using Google Apps Script that:

• Randomizes the standup order while grouping people from the same workstream together.
• Sends a Slack message every weekday morning at 9 AM with the order.
• Pulls the attendee list from a Google Spreadsheet, allowing easy updates.

This post walks through the entire setup, including code snippets, Slack integration, and lessons learned.

How the Automation Works

Attendee List in Google Sheets

The list of standup attendees is stored in a Google Sheet named “Attendees”. Each row contains:

• Active Column: Allows marking people as inactive (e.g. on vacation) to exclude them from the daily order.
• Workstream Column: Ensures that people from the same workstream appear together in the randomized order.

Google Apps Script Code

Step 1: Triggering the Script Daily

I set up a Google Apps Script time-based trigger to execute this script every day at 9 AM. However, my script contains a method called isWeekend() that checks if today is a weekend (Saturday or Sunday). If it is a weekend, the script exits without performing any further steps.

function isWeekend(date = new Date()) {
  return date.getDay() === 6 || date.getDay() === 0;
}

Step 2: Reading Data from Google Sheets

The script reads the attendee list and filters out inactive members:

function getTableDataFromSheet(sheetName, mapperFunc) {
  let sheet = SpreadsheetApp.getActive().getSheetByName(sheetName);
  let rawData = sheet.getDataRange().getValues();
  return rawData
    .filter((dataRow, idx) => idx > 0)
    .map(dataRow => mapperFunc(dataRow));
}

function loadPeople(sheetName) {
  const allFolks = getTableDataFromSheet(sheetName, (dataRow) => {
    return {
      name: dataRow[0],
      active: dataRow[1] === "Y",
      group: dataRow[2]  // Workstream grouping
    };
  });
  return allFolks.filter(person => person.active);
}

Step 3: Randomizing the Order

The script first groups attendees by workstream, then shuffles each group, and finally shuffles the group order:

function processOrderingFor(sheetName) {
  const people = loadPeople(sheetName);
  const groupedPeople = groupByWorkstream(people);
  const randomizedGroups = randomize(Object.keys(groupedPeople));
  
  const finalPeople = randomizedGroups.flatMap(group => randomize(groupedPeople[group]));
  sendNotice(finalPeople.join(", "));
}

function groupByWorkstream(people) {
  return people.reduce((accumulator, currentValue) => {
    if (!accumulator[currentValue.group]) {
      accumulator[currentValue.group] = [];
    }
    accumulator[currentValue.group].push(currentValue.name);
    return accumulator;
  }, {});
}

function randomize(list) {
  return list
    .map(item => ({ sort: Math.random(), value: item }))
    .sort((a, b) => a.sort - b.sort)
    .map(item => item.value);
}

Step 4: Sending to Slack via Webhook

I use a Slack automation triggered by a webhook that listens for a POST request and posts a message in the standup channel. (See instructions below on how to set this up in Slack)

function sendNotice(messageBody) {
  let slackUrl = 'https://hooks.slack.com/triggers/YOUR-WEBHOOK-URL';
  let options = {
    method: "POST",
    contentType: 'application/json',
    payload: JSON.stringify({
      order: messageBody
    })
  };

  try {
    UrlFetchApp.fetch(slackUrl, options);
  } catch (ex) {
    Logger.log(ex);
  }
}

Setting Up the Slack Integration

I used Slack Automations to handle the webhook request. The purpose of this integration is to receive the message from the Google Apps Script and post it in a Slack channel that the team uses for standup updates. You can also refer to Slack's official documentation on working with automations and triggering automations via webhooks for more details.

Here’s how:

1. Go to Slack Workflow Builder and create a new workflow.

2. Select “Starts with a Webhook” as the trigger.

3. Configure the webhook to accept a JSON payload with an order field.

4. Add a step to post the order field into the team’s Slack channel.

Edge Cases and Lessons Learned

While this automation works well, I encountered some challenges. Sometimes, people go on vacation but forget to update their status in the spreadsheet, meaning they still appear in the order. Similarly, new team members are not included until I manually add them. Another issue is that there are no failure alerts—if the Slack message fails due to network issues, I have to manually check and investigate why it didn’t show up.

Future Improvements

To improve accuracy and reduce manual maintenance, I plan to integrate the script with Google Calendar instead of relying on a Google Sheet. This would ensure the invite list is always up-to-date. Additionally, I will add logging and alerts to notify me if the script fails, helping with debugging and reliability.

From time to time, your direct report or colleague will take extended time away from work. It could be a parental leave or a sabbatical or an extended time off to take care of personal things. Whatever the reason, when they come back, they are going to be overwhelmed by the thousands of Slack and email notifications that they have missed while they were away.

I will be spending the next 2-3 days catching up on all the messages that I missed while I was out, so I will be slow to respond.

It’s common to find a Slack message like this from someone who has just returned. 2-3 days is a long time for getting all the context back, and almost always starts from not knowing where to start.

It doesn’t have to be like this. Do your returning colleague or direct report a huge favor, reduce their anxiety and get them caught up and productive again quickly. When they come back from their time away, have a short While You Were Out report ready for them. This report should capture all the important stuff that happened while they were out. They will gain all the relevant context quickly and will thank you from the bottom of their heart.

Here are some tips for writing such a report:

• Only write it for someone who is out for an extended period of time (which for me is 2 weeks or more). This effort isn’t worth it for anything less than 2 weeks of away time.
• Bullets are better than paragraphs of text.
• Not more than one page, please. Remember, it’s a tool to reduce time needed to gather relevant context. The report should only have stuff that matters, not everything that happened while the person was out.
• Don’t forget to include links to additional information/reference for each noteworthy item. An important organizational change that you are mentioning in the report? Make sure to add a link to the announcement that was sent to your engineering Slack channel.
• Gather notes while the person for whom you are writing is out. Don’t leave the compilation for one sitting, you aren’t going to remember every relevant detail. I make it a point to spend 5 mins every day adding noteworthy things that happened that day to a rough version. A day or so before the person comes back, I spend 10-15 mins to edit and polish the report.
• Co-create the report with someone else on the team. If that isn’t possible, at least have someone else review what you have compiled in the report.
• 🏆 Bonus tip: Once you have the report ready, use the schedule messages feature in Slack to ensure that the report is the first thing your colleague or direct see on their first day back at work.

While I have seen multiple formats, I use the 3Ps (People, Projects, Processes) format when I am compiling such a report for someone. Each P is a section with bullets with each bullet capturing something relevant/noteworthy.

Tags: #tips, #management