The STiCCS framework: expectations setting made easy

Setting expectations shouldn’t be a mind-wrenching task — so relax, make yourself a nice brew, and keep it easy with the STiCCS framework.

The topic of expectations setting is a recurring theme of my coaching sessions. This seemingly basic skill is actually one of the hardest to master, especially for newly promoted technical leaders who are used to the determinism of code but struggle with the ambiguity of human communication.
First thing first, the following point has to be clear.

You can’t hit a target you can’t clearly see

This simple truth applies to almost everything in life—archery, navigation, career planning, sport improvement, music, whatever. The problem is that, for some reasons, when it comes to leadership, we tend to forget it and we set vague goals, give ambiguous instructions, and then wonder why our teams miss the mark or don’t perform as we expect.
According to the Project Management Institute¹ companies that invest in communication and expectations setting deliver better results. Among those organizations considered highly effective communicators, 80 percent of projects meet original goals, versus only 52 percent at their minimally effective counterparts.
The cost of ambiguity can be huge and missed deadlines, wasted effort, team conflict, and disengagement are all problems that can be - most of the time - traced back to unclear expectations and foggy communication.
So how do we fix it?

The Two-Sided Problem

Before diving into solutions, let’s understand why this issue is so pervasive, particularly for new engineering managers. The problem here is that we are dealing with two different perspectives: the manager’s and the team’s.

The manager’s perspective

When you transition from individual contributor to manager, you face what psychologists call the “curse of knowledge.”
In a Stanford experiment conducted in 1990, researcher Elizabeth Newton asked people to tap out the rhythm (only the rhythm) of well-known songs while listeners tried to guess the tune². The people tapping predicted 50% success rate but, unfortunately, only 2.5% of listeners guessed correctly.
Why? Because tappers and listeners had different knowledge and were operating under a completely different context. The tappers heard the full melody in their heads while thinking about the song. The listeners, on the flip side, just heard disconnected taps.
This is exactly what happens when experienced engineers become managers; you know the systems, the context, the constraints, the history. When you say “improve the authentication system,” you hear the full melody, the architectural problems, the specific security vulnerability, the audit timeline, the architectural boundaries. Your team members just hears taps.
If this was not enough, we also have to consider the cognitive bias called “illusion of transparency”: our tendency to overestimate how well others understand our internal thoughts and intentions³. In other words, you think you’re being crystal clear when, in reality, you’re speaking a language that only you can understand.

The team member’s perspective

Now let’s flip the script. You’re a developer who just received an assignment from your new manager that goes like this:

We need to improve the authentication system. Can you take a look at it and make it better? Let’s aim to have something ready in a couple of weeks.

Yea, I know, there should be a circle in hell for the managers who give instructions this way, but still.
As you can imagine, there are many problems about this communication.
What does “improve” mean? Are we talking about better performance? Better security? Better user experience? Better what!?
What does “a couple of weeks” mean? 10 working days? 14 calendar days?
And what does “ready” mean? The feature is complete? Code reviewed? Deployed to production? POC?
The natural result is that, without clarity, team members usually:

• Ask too many questions and risk looking incompetent

• Make assumptions and risk building the wrong thing

• Do nothing and risk looking unmotivated

As you can imagine, none of these are good options.

The STiCCS framework

Frankly speaking, I got this wrong for a lot of years, so here’s a practical framework I developed for setting expectations that actually work. I called it the STiCCS framework, a structured approach to planning and evaluating projects that ensures clarity from start to finish.
It helps you define what you’re doing (Specificity), when it happens (Timeline), why it matters (Context), what could limit you (Constraints), and how success is measured (Success Criteria).

Specificity

“Work on the auth system” is not specific enough, a better job has to be done to define exactly what needs to be done, what we expect.

Example:

I need you to fix the security vulnerability in our OAuth implementation that was flagged in last week’s security audit (ticket SEC-123). Specifically, implement proper token validation and add rate limiting to prevent brute force attacks.

Notice the difference:

• Specific problem is identified (OAuth vulnerability)

• Reference point is provided (ticket SEC-123)

• Concrete deliverables are listed (token validation, rate limiting)

• Clear scope boundaries are underlined

Pro tip: Before delegating any task, write down the message you’ll use during the communication of the delegation. If you can’t articulate them clearly in writing, you’re most likely not ready to delegate it properly.

Timeline

Needless to say, being clear about the expected delivery time is absolutely paramount here. “A couple of weeks” means different things to different people, in such cases a precise date must be set in stone since the very beginning.

Example:

I need this completed by Friday, October 27th, end of day, because our security audit follow-up call is October 30th. We need buffer time for testing and documentation.

Milestones:
- Wednesday, Oct 20: Design proposal for review in our 1:1
- Friday, Oct 27: Implementation complete, tested, and deployed

Notice, here we have:

• Specific dates and times (not “end of week”)

• Rationale for the deadline (the audit call)

• Intermediate checkpoints (design proposal)

• Clear definition of “complete” (deployed, not just coded)

Pro tip: If the timeline is flexible, say so explicitly: “This is important but not urgent—I’d like it done by end of month, but if other priorities come up, let’s discuss.” Ambiguity about priority causes a lot of stress, be aware of it.

Context

People perform better when they understand purpose, but we often skip this step and jump directly to execution. This happens because we already know the why and assume everybody else can read our mind; remember the “illusion of transparency” mentioned above?
Explaining the business context and impact of a given activity is crucial to ensure that all possible edge case are considered by the person executing it and fosters a solid business-oriented culture.

Example:

This vulnerability was rated critical by our security team. We have a deadline from our enterprise client who won’t renew their contract unless we demonstrate SOC 2 compliance by end of quarter. This is blocking a $500K annual renewal.

The “why” serves multiple purposes:

• Helps people prioritize when conflicts arise

• Enables better decision-making when unexpected situations occur

• Builds intrinsic motivation (people care more when they understand impact)

• Creates psychological safety and accountability (people feel trusted with context)

Pro tip: If you find yourself thinking “they don’t need to know why, they just need to do it,” that’s a red flag and a mistake that I made myself. Adults deserve context so if the context is confidential, be clear about it rather than leaving an information vacuum.

Constraints

New managers often swing between two extremes: micromanaging every detail or providing zero guidance. I’ve been there, I did that too and I see a lot of managers making the same mistake.
The constraints and decision-making authority should be clarified at the beginning of the delegation.

Example:

You have full autonomy on the implementation approach, but here are the constraints:
- Use our existing OAuth library (no new dependencies without discussion)
- Follow TDD since this is security-critical
- Run your proposed solution by me before coding

Resources available: You can pair with Sarah, she implemented rate limiting for the API last quarter and can definitely help you out.

What to clarify:

• Boundaries: What can’t change? (technology stack, budget, timeline flexibility)

• Authority levels: What can they decide alone vs. what needs consultation?

• Available resources: Who can help? What documentation exists?

• Quality standards: What level of polish is expected?

Pro tip: The more experienced the person, the fewer constraints you typically need to specify. The level of detail can be tailored on the person taking over the task; let’s apply some Situational Leadership here.

Success Criteria

Different people have different definitions of “done.”, be sure that your own definition is properly communicated and correctly understood.

Example:

The task can be considered complete when:
- The security vulnerability is resolved (verified by re-running the security scanner)
- Unit tests cover the new validation logic (minimum 80% coverage)
- Rate limiting is implemented and manually tested (blocks after 5 failed attempts)
- Changes are documented in our security documentation
- Code is reviewed, merged to main, and deployed to production
- Ticket is updated with remediation details for the security team

This level of specificity might feel excessive, but it prevents the “I thought it was enough!” conversations that waste everyone’s time.

Pro tip: When possible, use the Definition of Done your team already has (from your development process) and add any task-specific criteria on top. This creates consistency and reduces cognitive load.

Conclusions

Setting clear expectations isn’t about being controlling or not trusting your team. It’s about respecting people’s time, respecting the importance of their work, and respecting them enough to give them what they need to be successful.
For new managers, especially those coming from technical backgrounds, this can feel uncomfortable at first and you might find yourself worrying about:

• Over-explaining or stating the obvious

• Coming across as condescending

• Not trusting your team with autonomy

But here’s the truth: your teams want clarity, they want to do great work and they want to meet your expectations. They just need to know what those expectations are and the STiCCS framework exists exactly to help you - and your team - getting on the same page.

1. Project Management Institute (2013), “Communication: The Message Is Clear,” PMI White Paper - https://www.pmi.org/learning/library/communication-11189.

2. Newton, E. (1990). “The Rocky Road from Actions to Intentions.” Dissertation, Stanford University - https://gwern.net/doc/psychology/cognitive-bias/illusion-of-depth/1990-newton.pdf

3. Gilovich, T., Savitsky, K., & Medvec, V. H. (1998). “The illusion of transparency: Biased assessments of others’ ability to read one’s emotional states.” Journal of Personality and Social Psychology, 75(2), 332-346 - https://pubmed.ncbi.nlm.nih.gov/9731312/