Expectations

Every single day, engineering teams need to do magic. Such magic manifests in several different shapes and forms. It could be by making hundreds of assumptions, figuring out what to do with little to zero context, and delivering decent solutions with proper architecture, design, comprehensive testing, and value via continuous delivery. It's a lot. In reality, most industries use Scrum/SAFE, which is far from the best way to work. In theory, when you are doing Scrum, if you do not finish a story during the spring, it's not a big deal; you go to the next one, shift the stories to the following spring, and it's all good. However, in reality, it is not exactly like that, unfortunately. That happens for various reasons: ignorance of what proper agile looks like, irrational pressure, industry pressure, and hundreds of other uncontrolled and hidden variables. Lean is all about learning to see waste, remove it, optimize it, and improve it with more quality. Companies, unfortunately, do the opposite; they just throw more bodies, do not re-think the process, and do not fix the monoliths; the result is an exposition of complexity in such a competitive environment where no company wants to stop a single day to do refactoring that engineering teams need to manage high expectations. Such an environment demands more from people; engineers need to be amazing hackers and be grounded in strong principles to have a shot.

Day by Day

Today, building software is much more challenging than it was 10-20 years ago. Companies do not want to stop and do the right thing; at scale, it is almost impossible because of competition, industry pressure, and various other reasons. So, you must learn how to improve as you go, or things will worsen no matter what. Every single company has legacy systems; in the past, it was often just one; today, there are always multiple legacy systems, all distributed monoliths full of terrible decisions, anti-patterns, and hidden bombs waiting for you during features and bugs. 

Often, an engineer needs to figure out things that only exist in the code; there is no documentation and no one to talk with, so for engineers to be successful in such environments, they need to learn how to extract information effectively from the code. Read code, debug code, and write down your own understanding is the way forward to navigate such complex waters.

The other part of the puzzle is the UX, followed by UI or experience. However you call it, you probably (for the frontend/mobile) have some scratch, prototype, or flow in a tool like Miro / Figma. That can be valuable even for backend engineers because you understand what's happening to some degree.  

Unspoken Expectations

I do not like story points. There are many problems story points create; IMHO, one of the big ones is the disconnect from real expectations. Yes, you can map story points to, say, in Excel and have that, but very few people do it. If you are going over mapping, why not take days anyway? The second problem is that even if you get the story points right, that does not translate to other teams, and when you need to do cross-planning or plan work across multiple teams, you have different understandings and expectations. 

Larger Planning

Even if your team does planning, there is always more considerable planning happening outside of your team's scope, whether you use SAFE or not. That planning is often part of even larger expectations, which can be per quarter or, in worse cases, multi-year. It's easy to get blind just looking at the sprint and miss the big picture. 

Director Due diligence

Usually, directors monitor engineering managers. That cycle can be per sprint or month, depending on how many teams the director needs to overwatch or even how many proper engineering managers he has. It's common to have gaps and a lack of managers on teams. This is not a problem with the right talent in place, but it could be a source of issues that will not happen immediately. It will take some time. Like any managers, directors have expectations of any engineer's delivery and performance; even when they don't say it, believe me, it's always there. The higher the seniority of the engineer, the higher the expectations.

Measurements and Awareness

I believe in explicit measurements. Think about this for a moment, if you do not measure, how do you know how long it takes, and how can you improve it? In an F1 race, where the team does not measure how long a car takes to do a lap, how will the team know if:

• Is the pilot driving faster or slower?
• Are the new tiers working better or performing worse?
• Does the new car engine make the car more or less competitive?

We know observability has a crucial role in distributed systems and software. But we forget that people and engineers also have an essential role. Engineers need to OWN their performance. One of the best ways for an engineer to OWN his performance is by doing the following:

• It's on you: Understand that no matter what happens, it's on you (delay? It's on you, missing details? It's on you, don't know how to test? It's on you, it's taking a long time? It's on you.).
• Flag it early: The best moment to flag problems is at the beginning of the work. Usually, engineers are pretty chill and figure things out as they go, but not flagging issues at the start is a big mistake. Flagging matters initially, like lack of details, missing rules, insufficient information on how to test, etc., allows people to calibrate faster. Better sooner than later. 
• Measure it: IMHO, having a simple Excel file where you have the link of your ticket, plus the day you start and the day you ended, capture the expectations of being done in days by your direct line manager is a great way to build ownership and know your own times. 

Reality and Chaos

Often, the reality is very chaotic. It's not uncommon to have the business, managers, and even designers that do not know what to do. That is fine, but when there is way too much noise, you need to focus on a POC rather than doing the actual work. IF no one has any idea what to do, how can you deliver? That's why when we focus on doing a POC, we shift the expectation from delivery to discovery. It 's okay to spend two weeks doing a POC to experiment with a couple of ideas; it might not be okay to take the same 2 weeks to get something done. 

A good planning process should detect which stories are rounded enough and ready for engineers to start and which ones need more POC and more discovery time. The reality is that. Often, planning and grooming happen, and that classification is missing, or most of the work is "not clear," the focus needs to be on discovery.

A common mistake companies make is believing that people know what needs to be done just because there is a "UX" or UI prototype. Remember, a company's reality at scale is full of complex distributed monoliths, and people need to read the code, dig, and figure out how to navigate them. 

Nature of Things

IF your team never does automated tests. It's very easy to keep that going forever. Because we enter on the "Auto-pilot" and the power of the habit make that happen effortless. That's why we must replace that bad habit with a good one, doing tests on all tasks, for instance. After 2 sprints, I would say it will be automatic, and you will make it effortless. 

The same goes for awareness and performance; if you are always paying attention to your performance, at some point, you will do that without effort, and it happens naturally. It's all about repetition and discipline. 

The first steps are always harder; people come up with all sorts of excuses:

• I don't like to read
• I don't like to read papers
• I'm doing great at work already
• It's okay to take 2 weeks to deliver a couple of files
• My team will never accept change
• We don't have time to change anything
• If I do refactoring, I will never deliver the story on time

It's easier to come up with excuses, but if we don't push back on some things as engineers, make the best decisions we can, and make the best use of our time, we are part of the problem, not part of the solution.

Every single company will want delivery. We won't do things without proper principles and decent practices, so get used to the fact that you need to be good at both delivery and quality. As much as it is difficult, it's possible.

Nature of People

People in nature want to do the right thing and want to improve. However, be very careful with what you do every day because that's what defines you, it's not what you think; it's what you do or what you do not do every day. The more you push people, more resistance you got. The less you push people, the less chance you gonna get. More meetings you do, less time your have to think and reflect. It's important to have time to think and reflect, even if you need to do it outside of work... do it.

Keep raiding the bar and challenging yourself. It is the best you can do for yourself and your team. People are social animals; when enough people deliver the same things and do the same things every day, the magic happens.

Extreme Ownership

Here is the truth, own it all. Every single task you get, do it above and beyond everybody expectations. Does not matter if they told it's your responsibility act it like you are the CEO and you own the whole company. The more ownership you take, the more you care, the more you act like an owner, deeper you will go and better you gonna work.

Ownership can be tricky when you do not agree with the decisions, or you instead do things differently. That does not mean you cannot still put your finger prints, your belives and make it your way, even following somebody else decision. No one call one the shots, even the CEO of a company. Learn how to play the game by taking ownership of even the worst problems, the worst code bases, the worst UIs, and the worst tests. Make them better. 

Own it, even if you hate it.

I build systems, and delivery complex projects at scale that I disagreed with the design and architecture decisions, that did not stop me to do a good job and improve other dimensions like testing, observability, migrations and be proud of the results.

Discipline

Discipline is everything; the more you pay attention to expectations and tune into hidden variables, the more effective you gonna be. It's not obvious. But the more you pay attention into details, and be curious, easier it gets over time. 

The reality is that in tech, documentation is never good enough and will never be. So there is no scape, we need to figure it out. By searching what exists in wiki pages, looking at Jira tickers, reading slack challenges, reading code, debugging it, and asking questions around. The more you exercise this muscle, the better you get, and the faster you figure out things. You need discipline and proactiveness to do it everyday, and belive me at scale you need it.

It's easy to raise your hands and say, "I'm blocked," or IDK. This exists. Go figure it out. 

Better Managing Expectations

Here is a summary of how we can do better, how we can better manage the expectations we get, even when these expectations are not explicitly communicated. You can know and do this:

• There are always expectations - even if no one tells you.
• There is always a date (even if people do not tell you).
• Few files should be done in 1-2 days max, 2 weeks no PR is bad. 2 weeks 1 PR is bad.
• Measure your own performance in an Excel file, explicitly ask your direct manager about expectations in days, and do not use story points.
• Own every single thing you do, make it better, every single file you touch.
• Do things daily, read daily, code POCs daily, and ask questions daily.
• Before you start any task, make sure you have what you need, if you don't have communicate as early as possible.
• Have a hacker mindset, go ask questions, go read wikipages, go read the code, go debug the code.
• Start your day with goals in mind = what did you finish today?

If you care about your work and want to do better, want your team to do better, but struggle with day by day and expectations, check out Continuous Modernization, my third book. Learn more on how to change the word a little bit every day.

Cheers,

Diego Pacheco