behavior management Team building

Turning Accountability into Action: Practical Tips for Leaders

The Merriam-Webster dictionary defines accountability as an obligation or willingness to accept responsibility or to account for one’s actions.

As leaders, we are often tasked with keeping our teams accountable and being accountable ourselves. The problem is that accountability is set as an expectation, but anyone in your organization will rarely show you how to hold your teams accountable.

Today, you don’t have to wonder anymore.

We’ll go over some common challenges leaders face, and explain a few ways you can enhance the accountability for yourself and your teams.

Let’s get started!

Why accountability?

If I were to further break down the definition of accountability, I would argue that our willingness to “accept responsibility” is further driven by our desire to belong.

Society works based on trust. We’ve learned that we can count on people to do what they say they’ll do, and when they don’t, we reduce our trust in them.

So accountability is about trust. It is our desire to know that I can trust you to do as you said you would.

Who are we accountable to?

Since we established that accountability is ultimately about trust when we are asked to hold our teams accountable, who are we expecting to trust?

I pondered about this for a while and ultimately understood that in business, we are always accountable to our customers. But we get there by being accountable to our peers.

When we talk about holding our teams accountable, we are, in essence, placing our trust in two critical directions: horizontally, toward our peers and colleagues, and vertically, toward our customers and stakeholders.

Trust in Our Peers and Colleagues (Horizontal Trust): Accountability within a team relies heavily on mutual trust among team members. As leaders, we expect our team members to trust us to provide guidance, resources, and support to help them achieve their goals. Simultaneously, we must trust our team members to fulfill their roles, meet their commitments, and contribute to the collective success of the team. This horizontal trust forms the bedrock of a cohesive and high-performing team.

Trust in Our Customers and Stakeholders (Vertical Trust): Ultimately, the success of any business hinges on the trust of its customers and stakeholders. We are accountable to them for delivering quality products, services, and experiences. To earn their trust, we must first demonstrate accountability within our teams. When our peers and colleagues trust us, this trust cascades vertically to our customers. They see a well-coordinated and accountable team dedicated to delivering value and meeting their needs.

Common challenges to helping your team be accountable

Celine Teoh, CEO Coach at Mochary Method, breaks down common challenges to accountability in their “How to Hold People Accountable” presentation. Let’s go over them in detail:

Ex-boss syndrome

Bad bosses are everywhere! luckily, since you are here, you care and are not one of those micromanagers that made you and your teammate’s life impossible. Don’t let a bad experience ruin the opportunity to build trust within your team to help them with accountability.

I am not an expert

How do you question someone more experienced than you? As leaders, likely, you are not the expert in the room, however, you are still accountable to your team and your customers.


You understand your team and feel deeply for the challenges they face. How can you expect accountability when their reasons are so valid?

I trust the team

You believe in your team and trust them so much you don’t feel the need to check on them.

Conflict avoidance

What if they get angry? what if my best employees leave? I am hesitant to hold them accountable out of fear of what they might do.

While these and other scenarios might seem valid to you, understand that to win over your customer and your peer’s trust, we have to overcome our fears and learn of ways to cultivate a culture of accountability.

Fostering an accountability culture

Carrots and Sticks

The prevalent way businesses have been fostering accountability has been by using carrots and sticks. If you are not familiar with the term, carrots, and sticks refer to when leaders use gifts (the carrot) as well as punishment (the stick) to incentivize behavior.

The basics of carrots and sticks look something like this

  • Set a goal and provide a bonus if you hit the goal (use a carrot)
  • No bonus if the goal is not met (remove the carrot)
  • We place you on a PIP and fire you if you don’t meet the goal (use a stick)
  • Meet your PIP goals and we won’t fire you (remove the stick)

Research has shown that carrots and sticks are well suited for tasks where the steps are well known. But well-known tasks are also tasks that are prone to automation, so we are left with a workforce whose value is created by being creative and solving challenging problems.

Unfortunately, carrots and sticks are detrimental when used to incentivize creative work. So how do we then get our teams, working on creative tasks, to be accountable for their work?

Intrinsic motivation

Rather than doing something to seek a reward or avoid a punishment, intrinsic motivation plays to our desire to do something simply because we find it interesting.

A great example provided by Dan Pink is the contrast between Microsoft’s Encarta encyclopedia and Wikipedia.

For Encarta, Microsoft went about implementing all the known carrot-and-stick approaches. Highly capable managers, a well-laid-out bonus structure, and very explicit goals.

On the other hand, Wikipedia is free to use and its content is entirely made from excited and engaged individuals who care for the information Wikipedia contains.

You don’t have to guess which encyclopedia is successful now. The intrinsic motivators driving Wikipedia contributions far outpaced any bonus structure put in place for Encarta.

How then do we foster intrinsic motivation to create a culture of accountability? Recent authors have given us excellent information on how to foster intrinsic motivation, here are some recent examples that I’ll use to illustrate actionable steps

These authors argue that when we care about something, we do a much better job at it, and to foster a culture of caring, we must help our teams understand the value they are adding and give them ownership over their work.

Let’s now take a look at specific action steps we can take as leaders to foster a culture of accountability by ensuring our team cares about their work.

Practical tips for leaders

A mental model I use to simplify what we’ve reviewed so far is that

“we foster accountability in our teams by providing autonomy via mastery and purpose”

This oversimplification covers most of the general idea, but let’s dig into the specifics of how we could implement it.


Your team works best when they feel ownership of their work, We allow for ownership by fostering autonomy, Here is how:

  • Define the mission and objectives clearly – follow up on progress on a pre-determined scheduled
  • Set high standards and clearly define what excellence looks like – repeat these often
  • Reaffirm your trust in your team. “I understand this work is challenging, and I want you to know that I believe in you and I have high expectations from your work.”
  • Allow decisions to happen where the information resides
  • Allow your team to choose their projects
  • Focus on outcomes rather than micromanaging the process
  • Let individuals define their own goals and metrics for success
  • Enable flexible work arrangements
  • Allow for open communication and active listening
  • Encourage your team to propose solutions
  • Foster “I intend to” statements by asking your team to bring up what they intend to do (new decision, next steps) rather than expecting you to tell them what to do next. On your end, focus on asking about the impact rather than focusing on the steps.
  • Don’t allow for excuses, autonomy = ownership. When given an excuse ask – what could we have done differently? what do you intend on doing next?
  • Lead by example by taking full responsibility for the successes and failures of your team. Never blame others or external factors for setbacks


It is extremely difficult for your team to achieve their tasks autonomously if they don’t have the knowledge and expertise required to complete them.

To have Autonomy, we require mastery, and mastery is achieved with grit (talent + effort). Here are a few ways to help your team achieve mastery:

  • Offer continuous learning opportunities
  • Allow your team to tackle challenging projects, stretching their current knowledge
  • Setup a mentorship program
  • Encourage your team to attend conferences
  • Encourage cross-functional collaboration, so your team learns from others and builds empathy toward sister groups
  • Solicit and Provide constructive feedback so your team knows where to improve
  • Frame mistakes or setbacks as opportunities for growth by holding retrospective meetings after projects to identify what went well and what could be improved, fostering a culture of continuous learning
  • Organize “learning days” where team members can dedicate time to exploring new technologies, tools, or methodologies.
  • Set up a “learning board” where team members can post and discuss lessons learned from various projects, promoting shared learning
  • Start a book club on a subject related to an upcoming project
  • Foster a culture of open communication and active listening, allowing team members to freely exchange ideas and insights
  • Facilitate regular peer reviews, where team members provide feedback and suggestions on each other’s work
  • Implement a feedback loop that allows the team to make data-driven adjustments.


To fully achieve Autonomy, Mastery, and Purpose, it is important to focus on the underlying reason for the work we do.

When we have a clear understanding of our purpose, we can take ownership of our work and feel empowered to achieve our goals independently, utilizing the skills and knowledge we have gained. To help your teams find purpose, follow these steps:

  • Communicate the team’s overarching mission and how each member’s work contributes to that larger purpose
  • Regularly remind team members of their work’s meaningful impact on the organization, customers, or society as a whole
  • Initiate discussions about the values and principles that guide the team’s work, helping individuals connect their tasks to a sense of purpose.
  • Involve team members in setting meaningful goals that align with the team’s mission and values, creating a sense of ownership
  • Encourage collaboration and teamwork by emphasizing the importance of mutual support within the team. Each team member should cover for and support their colleagues
  • Foster a culture where individuals are willing to step out of their comfort zones to help others in need, even if it means temporarily shifting focus from their tasks
  • Promote a “we before me” mentality, where the collective success of the team is always prioritized over individual achievements or agendas
  • Encourage team members to ask questions and seek clarification when they are unsure about the intent or the rationale behind a task. Promote a culture of curiosity
  • Help your team prioritize tasks and objectives based on their importance and impact on the overall mission. Focus on the most critical goals first
  • When facing a crisis or rapidly changing situation, remain calm and composed. Encourage your team to do the same and stick to the plan while making necessary adjustments

First 90 day plan – AI sponsored post

The first 90 days of a new job are critical for success. In order to make the most of this time, it is important to have a plan. The following is a suggested plan for the first 90 days:

  1. Establish your goals and priorities. What do you hope to accomplish in your new role? What are your top priorities?
  2. Get oriented. Learn about the company, its culture, and its products or services. Talk to people in different departments and get their perspectives on what it’s like to work at the company.
  3. Develop relationships with key people in the organization . Who are the key players in your department and across the company? Build relationships with them by asking questions, seeking advice, and collaborating on projects whenever possible.”

– this small blog post was written by an AI from you.com via https://t.co/hJihfuex9D

contractors management

Working with contractors

Recently, we’re getting ready to engage with contractors to help us drive a major initiative forward.

Behind the scenes at work, here is a view that happens before contractors write any code.


It starts by figuring out what company you’ll be working with. 

Your company might already have a pre-vetted list of vendors, but we reached out internally for recommendations in our case. After meeting with a few representatives, we settled on a couple of companies we liked.

To decide on one of them, we created a weighted decision matrix. We rated both companies in pricing, availability, expertise, onboarding times, size, and a few other attributes essential to our decision-making criteria. 


It is time to make things official with a company in mind. 

On our end, we have legal counsel to help us draft the needed documents, but you can reach out to the vendor and ask them to send you the first draft instead.

You can expect two documents, a Master Service Agreement (MSA) and a Statement of Work (SOW).

Please think of the MSA as the contract allowing both companies to do business with each other, while the SOW will go into the specifics for each engagement you have with them.

As an example, the MSA could contain non-compete, non-solicitation, or security requirements applying to all contractors. On the other hand, the SOW will have working hours, deliverables, pay rates, and additional job-specific information.

It is common to have one MSA and one or more SOWs.

Selecting contractors

With all the legalities in place, it is time to start figuring out who’ll be doing work for you.

Whether it is a long-term engagement or work with a well-defined deliverable, you will need to determine the technology stack and the level of experience expected.

The vendor typically does some initial candidate vetting and will present a few options for you to select from.

It is on you to further develop a process to validate that candidates meet your expectations.

That means a quick engineering assignment that we then review internally.

Product engagement

With a team ready, they’ll need to know what they will be working on. This is where your product manager comes in.

Just like your team needs guidance on the product and an understanding of priorities, so will your contractors.

Engineering engagement

With good direction, your contractors will now be ready to start work, so we’ll need to get deeper into specifics.

Think about items such as level of access to your repositories, reviewing pull requests, CI/CD checks, release strategies, getting the code working locally.

In reality, this part doesn’t look much different from the engineering onboarding your employees might go through.


Engaging with contractors is an excellent way to augment your workforce and make further progress on your initiatives.

But to ensure a successful engagement, it helps to:

  • have a procurement process to land on a suitable partner
  • understand the standard legal contracts used
  • have a way to examine engineers for your required expertise
  • please provide them with the necessary support to seamlessly work on what is important to you.

Contractor icons created by juicy_fish – Flaticon

empathy management stories

Project empathy — day five – logic and the first test

Today felt productive, engaging, and like I finally made real progress.

Here is how the day went.

I created a new ProjectManager class to contain the logic for the project domain.

Since I am exposing the most straightforward functionality, I only added create and read methods, with creation only having a title as a required field.

Since I added new logic, I felt it pertinent to cover the logic under tests.

Luckily, the framework took care of a lot of the initialization items needed to test, such as 

  • In-memory DB
  • Seeding test data
  • Faking auths as various users
  • Dependency injection
  • Testing frameworks such as xunit and shouldly.
  • Sample tests to get you started

I can only imagine the amount of time it would have taken to set everything up to a point necessary to run a test.

With that note, I remember when I was getting started, I found the time required to set up tests quite challenging, especially when thinking about all the feature work I could be working on.

The learning here is that it isn’t enough to expect tests to be done. We need to dig deeper and embed within our teams the importance and value-added of having quality software.

Until next time.

Icons made by Freepik from www.flaticon.com

empathy management stories Uncategorized

Project empathy, day four — first new code

Day four was fun but short.

I began by setting my Pomodoro timer to 25 minutes to work on the first milestone, creating and viewing projects.

The project’s definition already has a lot of functionality, so I constrained the milestone only to include the title as part of the project.

The framework I am using https://aspnetboilerplate.com is highly opinionated, so I had to spend my first Pomodoro timer just browsing through the docs in order to get acquainted with it.

For my second Pomodoro, I wrote our first class, the project class. I added the database migrations and pushed them to the database.

I mentioned that the framework I am using is highly opinionated. It uses domain-driven design, so our class has no logic and can only be instantiated via a create method, ensuring that domain rules are applied consistently.

The logic will be added to another class they call “the manager” you can see more details on their design here.

So far, this little project has proven successful in building empathy. I had already forgotten that there is a significant amount of time devoted to research and learning for every line of code.

empathy management stories

Project empathy, day three — milestones

Day 3 took me towards project management; here is what happened.

I managed to get 30 minutes in before the end of my day, so I was determined to make the most out of them.

Recently, someone shared an article on project management and the importance of setting milestones rather than features.

Using the concept on our project means that I’ll work on delivering a subset of the functionality rather than a full feature.

So I created a milestone in GitHub and got started on it.

I spend most of the time thinking about what the milestone should contain and how to break up the work.

During the last two minutes of the Pomodoro timer, I created a branch in source control.

I am hopeful that next time I’ll be able to get started on actual code 👨‍💻

empathy growth habits management

Project empathy, day two

For day two of our project, I only got in 30 minutes of work. Here is how that went.

Since I am in management, I am constantly in project management and productivity software such as Jira and Todoist.

The idea is to build a project management tool that feels as simple as todoist.

Doing so should get me into design, architecture, and software system implementation.

Thus reminding myself of what it is like to do all the things I expect of engineers in my teams.

With this in mind, I created a few documentation tasks and got started on the first one, defining a `project.`

The deliverable requires a model, commands, queries, events, API consumers, and dependencies.

Luckily, I found a microservices canvas that neatly organizes the areas I hoped to document.

I copied it into our repository and filled it out with `project` details. 

Check out the draft here https://github.com/toyiyo/todo/blob/issue-3-define-project/services%20canvas/project.adoc

For day two, I figured out what I wanted this project to shape and started a documentation task via a microservices canvas template.

Stay tuned for day three.

management stories Team building

Project empathy, day one

Today was my first-day writing code for what I call “the empathy project” to build empathy for what engineers go through.

Here is how my first day went.

I started with an existing template to give a good starting point. After following the instructions, I downloaded the template and ran into my first error.

Something about a secrets.json file not found. Why is this template looking for that file? No idea, so I go on google to find my answer.

After multiple articles, I found a stack overflow answer that looked promising.

I tried their solution and ended up getting through my first bump!

Since I changed the project, I figure I needed to add it to source control, you know, so I won’t lose all the hard work that cost me a ton of reading to get to the one-line change I made.

So I create a repository in GitHub and then attempt to upload my existing project to it.

The second issue of the day, I forgot my git commands 😭, so I got on Google again to refresh my mind.

I managed to upload to GitHub and create a new branch — success.

Ok, let’s try to build and rerun the project. Another error shows up. This time it is something related to the connection string to my database.

Wait, database? I didn’t set one up yet. So I get on google again to figure out what people like to use nowadays for starter projects.

The template I used uses entity framework, a Microsoft ORM, so I’ll need a relational database.

My search takes me to Heroku. Since they have a free tier for their Postgres DB, I create an account and copy the connection string.

This part I remember, add the connection string to the config file, and we’re good to go, right?

Not so fast. After adding the connection string, I type the run command and run into one more error 😨something about the connection not being secure.

This one took a lot of trial and error, google gave me the answer, but things didn’t seem to work.

The solution turned out to be the difference between typing “SSL Mode” vs. “sslmode.”

Ok, it looks like I can connect to now, I run the project once again, and this time the browser shows up for about one second… it just blinked in front of me, then disappeared with all my hopes.

This time, we appear to be missing our database tables.

I missed a step in the instructions and forgot about database migrations.

Ok, let’s run the existing migrations, and we’re good to go, or so I thought… I tried running the migrations, and more errors showed up.

More googling and lots of reading through the docs to uncover that the existing migrations were done for SQL Server and not compatible with Postgres.

I deleted the migrations, created new ones, and tried again. This time, the tables get made, and my hopes are back.

I type the run command again and cross my fingers, hoping that things will be ok this time.

Things are loading. My terminal is showing more messages than before. For a second, I can see into the matrix.

But then, big red messages pass by quickly, and everything stops again. I am deflated now. What else could it be?

The logs show a problem with an insert statement with a date-time field of type local, but the column only supports UTC.

At first, I start reading into the date-time type in Dotnet core, and sure enough, there is an attribute to set the type, but there is no default value, so my error isn’t making sense. Somewhere in the code, we’re setting date times to local.

After more searching, I found the code to insert data to the DB. It was passing clock.now. I looked into clock. I figured out it is part of the template and not the framework, so I quickly searched the documentation and changed the default type to UTC for clock.

Let’s try again! Things are running, and finally, the browser opens up to the login screen.

I was thrilled and tried to log in with the default credentials provided.

I got redirected to a JSON blob 😭.

I am about to cry now.

The logs are not showing anything meaningful this time, so I checked the network settings in the browser and saw a bunch of errors related to files not loading, yikes.

More reading and googling, this is getting old, anyway, I now have to build my front end by running another command.

This time, everything should work.

I run the run command, and everything seems to be working well for the first time.

The pages show up. I can log in and do quick updates.

I am now ready to commit and push to source control.

I am reviewing what I am sending, and oh the horror, config files with credentials to my DB!

This should be easy. I’ll have to move the connection string to the secrets.json file so that it is only available on my machine 😊

Well, that didn’t work. Moving the connection string caused me to lose connectivity to the DB.

I do more googling to figure out why I can’t read from the secrets file, but I am increasingly frustrated, so I decide to go with what is familiar to me, environment variables.

I set my connection string to an environment variable, updated the code to read from the environment variable instead of configuration files, and reran everything. Success! This time for real.

I feel good about pushing my code, I looked at the time, and it has been over five hours, to my surprise.

If the success criteria for the project is to build empathy for engineers, day one proved to be highly successful.

I’ll pick this up after the holidays, so stay tuned for day two.

Icons made by berkahicon from www.flaticon.com

management strategy

Change management – taming the rumor mill

The rumor mill is hard to contain and impossible to stop.

After all, people are curious, and when they know change is coming, they want to know a few things

  • How am I affected?
  • When is it happening?
  • Is it good or bad?
  • How are those around me affected?
  • Who do I go to with questions?

As leaders, our reports will expect us to answer these questions and more.

To better serve them, get a document started, have a meeting, or go to a Cafe with your peers and figure out as much information about the change.

Consider main themes such as 

  • Reporting structure
  • Process
  • Direction
  • Compensation
  • Timelines
  • Documentations
  • Reasoning
  • Decision-makers

Next, consider the communication preferences and must-haves to disseminate the information, such as

  • Legal requirements
  • Communication channels — think meetings, documents, presentations, videos, phone calls
  • Timing on communication 
  • Chain of responsibility for communication

By now, you should have a proper change management plan to execute on and hopefully slow down the rumors from presenting an inaccurate future.

Icons made by Eucalyp from www.flaticon.com

growth management

A short one

Well, I lost my daily writing streak.

I got some back pain, heavy days at work, and busy afternoons with the kids.

By the time 8 PM rolls around, I am exhausted and not really in the mood to write.

But here I am, at 6:23 CST on December 1st, 2021, trying to pick up where I left off while my kid makes a mess in the bathroom by spreading toothpaste all over the counter!

I usually try to tie these quick stories to business perspectives, so here it goes.

We have ups and downs, and busy lifestyle outside of work.

While this should be obvious to all of you reading, as managers, I believe we somehow forget that this is the case and continue pushing our teams for consistency in excellent outputs all year round.

Never forget there is more to life than your job.

Icons made by Vectors Market from www.flaticon.com