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
strategy Team building

The Rewards of Stepping Outside Your Comfort Zone: How to Encourage Your Team to Try Something New

As a software engineer, it’s easy to get comfortable with the tools and processes that we use daily.

We know them inside and out, and they help us get our work done efficiently.

However, it’s important to remember that there is always room for improvement and that stepping outside our comfort zones can lead to significant rewards.

In this blog, we’ll discuss the benefits of trying new things, how to overcome the fear of change, and how to encourage your team to step outside of their comfort zones.

The benefits of trying new things

Trying new processes can lead to increased efficiency and productivity.

For example, adopting a new tool or framework might take some time to learn, but it could ultimately save your team a significant amount of time in the long run.

Additionally, learning new skills keeps us competitive and helps us stay up-to-date with the latest technologies.

It’s also important to stay open to change and be willing to adapt.

The world of software engineering is constantly evolving, and those who are open to new ideas and approaches are more likely to succeed.

Overcoming the fear of change

We know that change can be intimidating, especially when we’re used to doing things a certain way.

However, we can overcome this fear and embrace new processes.

One way to do this is to break the process down into smaller steps.

This can help make the transition feel more manageable and less overwhelming.

It’s also helpful to find a support system, whether a colleague or a mentor, to help you through the process.

Finally, it’s essential to focus on the potential rewards of trying something new.

Think about how the new process will benefit you and your team in the long run.

Encouraging your team to step outside their comfort zone

As a leader, it’s essential to lead by example and be willing to try new things yourself.

This sets a good precedent for your team and shows them that embracing change is ok.

Encourage open communication and encourage team members to share their ideas and concerns.

This creates a culture of innovation and encourages people to think outside the box.

Additionally, offer support and resources to help team members feel more comfortable trying new things.

This might include training sessions or additional support during the transition period.


Hopefully, after reading this far, you are more inclined to try something new to enhance your engineering journey.

It creates a culture of innovation, keeps us competitive, and can be exciting.

strategy Team building

Maximizing Domain Impact through Team Design

Domain-driven design is a software development approach emphasizing the importance of understanding the business domain to design effective software solutions.

At the heart of this approach is the idea that software development should be driven by the needs and constraints of the business domain, rather than being driven purely by technical considerations.

Understand the business

One key aspect of domain-driven design is the use of domains to structure the design of a software system.

A domain is a specific area of knowledge or expertise, such as customer management or inventory management.

By starting with a clear understanding of the business domains that a software system will need to support, it becomes much easier to design software components that are well-suited to the needs of the business.

Software components supporting the domain

Once the domains have been identified and understood, the next step is to move down to the level of software components.

These are the individual pieces of software that make up the system and should be designed to reduce the cognitive load on the team.

Each component should be designed to be as self-contained and easy to understand as possible, so that team members can focus on their areas of expertise without being bogged down by complex dependencies or unfamiliar concepts.

Team topologies

When designing a team, there are a few different topologies to consider.

One option is the stream-aligned team, which is focused on a specific business domain or set of related domains.

This can be a good choice when the business domain is relatively simple, and there is a precise alignment between the business goals and the software requirements.

Another option is the platform team, which is focused on building reusable software components that can be shared across multiple business domains.

This can be a good choice when the business has a wide range of domains that need to be supported and when there are significant opportunities for reuse and code sharing.

Finally, there are complicated subsystem teams focused on building large, complex software systems made up of many interconnected components.

This can be a good choice when the business has complex requirements requiring a highly specialized team to implement.

Overall, the key to success with domain-driven team design is to start by understanding the business domains the software will need to support and then design software components and teams that are well-suited to these domains.

By doing so, it is possible to build software systems that are effective, maintainable, and easy to understand, which can help to reduce the cognitive load on the team and improve overall team productivity

behavior Team building

The Power of ‘We’: How Changing One Word Can Transform group Dynamics

Have you ever noticed how using the word “they” can create a sense of separation and division within an organization?

It’s almost as if you can see the wall being built between groups when they refer to each other as “they.” But what if we told you that changing just one word – “they” to “we” – could help break down those walls and promote unity within your team? This idea is explored in depth in the book “Leadership is Language” by David Marquet.

Using “we” instead of “they” can have a powerful impact on team dynamics and help foster a more cohesive and collaborative environment.

When you use “we,” you are including yourself in the group and implying that you are all working towards a common goal.

It sends a message that you are all in this together and willing to support and help each other.

For example, let’s say a team needs help with meeting deadlines. Instead of saying, “they need to work faster,” a more practical approach might be to say, “we need to find ways to improve our efficiency and meet these deadlines.”

This shift in language acknowledges that the problem affects the entire team and encourages everyone to be a part of the solution.

It also aligns with extreme ownership, where each team member takes responsibility for their actions and works to find ways within their control to do better.

On the other hand, using “they” can create a sense of distance and disconnection within a team. It suggests that there are “us” and “them” and that you are not a part of the same team.

This can lead to a breakdown in communication and a lack of trust between team members.

So next time you find yourself using “they,” try swapping it out for “we” instead.

It may seem like a small change, but it can significantly affect how your team functions and works together.

Collaboration icons created by Freepik – Flaticon

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

Hiring management Team building

Seeding new teams

We’re currently trying to seed a new team to work on a high profile high-value initiative.

In this post, I will walk you through the different options we came up with, as well as the DACI format we’re using to get to a decision.

Existing team

The fastest option but also the one that carries the most risk.

Existing teams already own components and have plans for them in the future.

By switching priorities over to this new initiative, they will have to drop their work and ownership onto someone else’s plate or decide that there is no value in engaging in the work, which could have very real negative business impact.

Add to that the human factor. You usually join a team, make plans, and have certain expectations of the work you will be doing.

Now imagine that suddenly, the company decides to switch directions and sends you over to go build something entirely different.

Depending on what the new work is, this might sound like a fascinating opportunity or a terrifying one that could cause some churn within the company.

New team

The most time-consuming option is establishing an entirely new team.

It takes an average of three months to hire a new engineer, even longer to hire an engineering manager, a product owner and a designer.

Add another three months or so of onboarding time and we’re saying that if we start today we will see progress on this initiative in about six months.

Internal recruiting

This in-between option means that we seed the team initially from within but, unlike option number one, where we’re using an existing team, we will open up a requisition to gather interest from within the company and go through our internal hiring process to seed the initial squad.

The approach comes with a few advantages and disadvantages.

On the plus side, we ensure that interested individuals actually join the team.

It is also less time-consuming than hiring externally.

It is possibly less disruptive than removing an entire team, given that ideally, the individuals will come from multiple parts of the company.

On the negative side, it does take longer than just taking an entire team and switching directions for them.

There’s also the risk that no one shows up or is interested in the work.

As well as the unlikely option that an entire team would want to move over.


While we have not decided what we’re going to do, I’ll talk a bit about the DACI framework used to get to a decision.

The framework stands for driver, approvers, contributors, informed.

The driver’s job is to initiate the process and gather all the approvals, contributors, and people that need to be informed of the decision.

The driver could also be in one of the other statuses.

The approvers will provide feedback, contribute to the decision, and ultimately make a decision.

Contributors are different stakeholders that will offer some input or based on their expertise.

Informed are the group of stakeholders that will need to be made aware of the decision.

With very well-defined roles, the process is simple.

We start a document with an initial summary that displays multiple options, such as the ones we included at the beginning of this blog post.

We include any risks that we believe there to be with each option.

We sent the document to everyone in the approval and contributor groups and set a deadline to give everyone enough time to provide their feedback.

Once everyone has given their input and provided their preferred option, the approvers will get together and make the final decision.

The last step is to inform the people in the “informed” group.

Icons made by Flat Icons from www.flaticon.com

management Team building

Check your team’s pulse

Imagine yourself as the sparkling new manager of a team, like any good manager, you listen attentively, trying to learn anything and everything there is to know about your team.

You set up one on one meetings, embed yourself in your team’s processes, and get to know all stakeholders personally.

All great initial steps for your first 90 days, but is that enough? can we determine if there is trust within your team? do you know if they have all the tools they need? can you figure this out consistently? Can you devise a team-building strategy?

Next, I’ll introduce a consistent, simple, and proven technique to get a good hold of your team’s pulse, allowing you to plan accordingly to meet your team’s needs and expectations.

Introducing – the survey

Surveys have been around for a while, and they tend to stick around because they are excellent tools to gather information consistently, allowing for anonymity when desired, and being useful to visualize changes over time by running the same survey at given time intervals.

The surveys I am about to present came from different sources.

I used books such as

As well as my own experiences in various managerial roles.

I aimed to get a pulse at the company level, drilling down to the team level, and lastly to the individual, which resulted in 3 different surveys being created.

Workplace survey

The first survey covers the state of the workplace.

12 questions should be studied in blocks of 3 questions at a time.

Each 3 question block is meant to build on the following 3 questions, in other words, if we find that we are doing bad on any 3 question block, the earliest block is the one we need to concentrate our efforts before we try to fix any of the subsequent blocks.

Think of each set of 3 questions as a step in a pyramid, with the first step being the base for everything else.

Company basics

The first set of questions will surface if your team knows what they are supposed to do, have been given the materials they need, and if they are working on what they enjoy.

All statements receive a rank from 1 to 5, where 5 denotes strong agreement with the statement

  • I know what is expected of me at work
  • I have the materials and equipment to do my work right
  • At work, I have the opportunity to do what I do best every day

Care for the individual

We now move from the basics to the individual. We want to know if we are caring enough that it is noticeable. People don’t stay at jobs where they don’t feel appreciated.

  • In the last 7 days, I have received recognition or praise for a job well done
  • My supervisor, or someone at work, seems to care about me as a person
  • There is someone at work who encourages my development


While the prior questions focused on a top-down view of the individual, this set of questions try to get the story of how the individual perceives their contributions are being received, as well their alignment with the company’s mission.

  • At work, my opinions seem to count
  • The mission and purpose of my company makes me feel my job is important
  • My associates are committed to doing quality work

Personal growth

The last set of questions is about growing as a person. Understanding that maturing with us is a winning proposition for everyone.

  • I have a best friend at work
  • In the last six months, someone at work has talked to me about my progress
  • This last year, I have had opportunities at work to learn and grow

Team survey

Our team survey is mostly based on the 5 dysfunctions of a team, and similar to the workplace survey, we group the questions in such a way that we can get answers to very specific needs.

We are ranking statements from 1 to 5 as well, with 5 determining strong agreement.

Absence of trust

Trust leads to excellent teamwork, open communication, and probably more important, actually looking forward to working with your team.

The statements to surface absence of trust are as follows

  • Team members quickly apologize when they do something damaging to the team
  • Team members openly admit their weakness and mistakes
  • Team members know about one another personal lives and are comfortable discussing them

Fear of conflict

This section is all about ensuring that we don’t ignore controversial topics, that all opinions and perspectives are heard, and that no time is wasted in interpersonal risk management (appearing to be something we are not)

  • Team members are passionate and unguarded in their discussion of issues
  • Team meetings are compelling and not boring
  • During team meetings, the most important, and difficult, issues are put on the table and resolved

Lack of commitment

Not suffering from lack of commitment means that we have clarity around the direction and priorities for the team.

As well as being aligned around a common objective and having the ability to change direction without hesitation or guilt.

  • Team members know what their peers are working on and how they contribute to the collective of the team
  • Team members leave meetings confident that their peers are completely committed to the decision that was agreed on, even if there was initial disagreement
  • Team members end discussions with clear and specific resolutions and calls to action

Avoidance of accountability

Accountability aims to improve performance. Peer pressure, while not politically correct, maintains a high standard of performance for any team.

If your team suffers from avoidance of accountability, some proven techniques include increasing pair programming efforts, surfacing goals and standards, and constantly reviewing your progress against them.

  • Team members call out one another deficiencies or unproductive behaviors
  • Team members are deeply concerned about the prospect of letting down their peers
  • Team members challenge one another about their plans and approaches

Inattention to results

When we care about something other than the collective goals of the group, it becomes very difficult to show meaningful results.

We must be careful about what a celebration looks like, think about the reasons for Wikipedia to be so successful. It has nothing to do with money or status, and everything to do with buy-in and passion for knowledge.

With that said, if your team suffers from inattention to results, some proven techniques include committing publicly to specific results and celebrating your achievements.

  • Team members willingly make sacrifices (such as taking on support) for the good of the team
  • Morale is significantly affected by the failure to achieve team goals
  • Team members are slow to seek credit for their contributions but quick to point out those of others

Individual autonomy survey

The individual survey is all about autonomy.

Using Carrots and sticks to influence behavior has been very effective to get performance gains on work that already has a predetermined solution.

Think of work that you could put in a to-do list, and requires mostly effort, and not thinking, to complete it.

In other words, when the solution is known and we just have to implement it, carrots and sticks work extremely well.

Carrots and sticks, however, has been proven to decrease performance on any type of work that requires any amount of thinking and creativity

A good presentation on the subject can be watched here

How do you achieve performance, results, and keep people happy if rewards and punishment are ineffective?

You allow for autonomy, mastery, and purpose.

The prior surveys already touched on mastery and purpose, so I am concentrating on knowing how much autonomy the team has to perform their work.

  • How much autonomy do you have over your tasks
  • How much autonomy do you have over your time
  • How much autonomy do you have over who you work with
  • How much autonomy do you have over your technique

To close up on autonomy, an easy way to think about it is

do not micromanage and lead with questions.

Icons made by Freepik from www.flaticon.com