I started leveraging this approach heavily when kicking off a large-scale project where I had identified over 50 key decisions. With discovery being paramount, it was simply infeasible to thoroughly research every single decision before launching a prototype or beta to gather crucial user feedback. This forced a pragmatic approach to decision-making.

At its core, this framework hinges on understanding two fundamental types of costs:

1. The Cost of Making the Wrong Decision: This refers to the negative consequences that arise from committing to a suboptimal path. These can be direct or indirect, and often compound over time.

2. The Cost of Delaying a Decision: This is the value lost or cost incurred by not making a decision in a timely manner. It represents missed opportunities, prolonged uncertainty, and potential setbacks.

My guiding principle has become: whenever you can delay a decision, you should. Why? Because waiting often allows you to gather more information, observe real-world outcomes, and reduce uncertainty, thereby increasing the likelihood of making a better decision. However, this isn’t a blanket rule. If delaying a decision means sacrificing significant value, such as a critical business opportunity or market advantage, then making an early, albeit potentially less informed, decision is the wiser course of action.

Let’s dive deeper into these two costs:

Understanding the “Cost of Wrong Decision”

The cost of a wrong decision can manifest in various ways:

• Rework and Reruns: Implementing something incorrectly means time and effort spent building it, only to tear it down and rebuild. This directly wastes engineering resources.

• Technical Debt Accumulation: Poor architectural choices or rushed implementations often lead to technical debt, which incurs ongoing costs for maintenance, slower future development, and increased bug fixing.

• Performance Issues and Scalability Limitations: A wrong decision in system design can lead to poor performance, hindering user experience and potentially requiring costly refactoring or infrastructure upgrades later.

• Security Vulnerabilities: A flawed security decision can lead to breaches, data loss, reputational damage, and significant legal and financial repercussions.

• Loss of Business Opportunity: If a product or feature is built incorrectly, it might fail to meet market needs, leading to lost revenue or market share.

• Impact on Team Morale: Repeatedly working on things that get thrown away, or battling against fundamental design flaws, can significantly demoralize a team.

Quantifying this cost can be challenging, as some impacts are indirect or long-term. However, even a qualitative understanding of the potential fallout is crucial.

Deconstructing the “Cost of Delay”

The cost of delay, often underestimated, can be equally, if not more, impactful:

• Lost Revenue/Business Value: If a feature or product could generate revenue or deliver significant business value, every day of delay means lost income or competitive advantage. Think of a critical compliance feature or a new product that unlocks a new market segment.

• Missed Market Opportunities: In fast-moving industries, being late to market can mean missing a window of opportunity entirely, allowing competitors to gain a foothold.

• Increased Project Costs: Delays can lead to extended team allocation, prolonged infrastructure usage, and increased overheads, directly inflating project budgets.

• Erosion of Customer Trust/Satisfaction: Users expect continuous improvement and new features. Delays can lead to frustration and a perception of stagnation, potentially driving users to alternatives.

• Dependency Blockers: Delaying a decision on one component can block progress on multiple dependent features or teams, creating a cascading effect of delays across the organization.

• Increased Uncertainty: The longer a decision is delayed, the more uncertain the path forward becomes, making future planning more difficult and introducing more risk.

The Decision Matrix: Cost of Delay vs. Cost of Wrong Decision

To make this framework actionable, we can visualize these two costs in a simple 2x2 matrix:

Let’s break down each quadrant:

• Low Cost of Delay, Low Cost of Wrong Decision (Defer or Default)

  • Description: Decisions here typically involve minor details or reversible choices where the impact of being wrong is small, and waiting doesn’t significantly hinder progress.

  • Action: Defer the decision until more information is naturally available, or default to a reasonable path if a quick decision is needed. Examples: Minor UI tweaks, naming conventions for internal variables, or initial logging levels. These can be iterated on easily.

• Low Cost of Delay, High Cost of Wrong Decision (Research & Validate)

  • Description: These are decisions where the immediate impact of not deciding isn’t high, but getting it wrong could have significant negative consequences.

  • Action: Invest time in thorough research, prototyping, and validation. Seek expert opinions, conduct experiments, or run small proofs-of-concept. Examples: Choosing a core database technology, selecting a major third-party integration, or defining a critical API contract that will be used by many consumers.

• High Cost of Delay, Low Cost of Wrong Decision (Decide & Act Quickly)

  • Description: This quadrant often contains decisions that are time-sensitive but where the consequences of being wrong are relatively contained and reversible.

  • Action: Make a decision swiftly, even with imperfect information. Prioritize getting something out to learn and iterate. Bias towards action. Examples: Launching an MVP with a core feature set, deciding on a rapid marketing campaign, or making an urgent bug fix that unblocks critical business operations. The “fail fast, learn fast” mentality thrives here.

• High Cost of Delay, High Cost of Wrong Decision (Strategic & Careful)

  • Description: These are the big, high-stakes decisions. Delaying them has significant negative consequences, but so does getting them wrong. This is the highest priority quadrant.

  • Action: These require careful consideration, senior stakeholder alignment, and potentially phased rollouts or robust rollback plans. Mitigation strategies for both delay and error are paramount. Examples: Major architectural paradigm shifts (e.g., monolith to microservices), large-scale platform migrations, or entering a completely new product market.

Implementation Cost

The “cost of a wrong decision” and “cost of no decision” also need to be evaluated against an implementation cost. Here’s were we find some rough edges in this framework and where the highest potential for improvements (or even just improved rationale).

From low Cost of Delay (No) Decision we still need a way to understand if we should default or defer. Using an implementation cost is one way to improve that decision. Cost of Wrong Decision is in to some extent dependent on the imagined implementation. But I’ve found that contrasting to the implementation cost is, currently, the best approach to getting to a guiding result.

External vs. Internal Costs

While actively using this framework I realized that I needed to understand who to involve to make a sound decision. To assist with that I introduced the split between external and internal costs.

• External Costs are incurred by parties outside your business, such as customers or partners. These could include a customer experiencing an issue that requires them to spend hours instead of minutes to complete a task, a vendor being unable to integrate with a new API, a loss of brand reputation from a security breach, or a drop in customer conversion rates.

• Internal Costs are those experienced by the business itself. This includes everything from wasted engineering effort and missed market opportunities to increased operational overhead (like higher cloud bills), reduced team morale due to technical debt, and licensing fees for incorrect tool choices.

Practical Approach with a Decision Scorecard

While a simple 2x2 matrix is great for high-level thinking, we can use a scorecard to handle more variables and quantify decisions. This helps us prioritize and make trade-offs on a more granular level.

My approach has been to build a spreadsheet with all project aspects and rate each on a logarithmic scale (e.g., 1, 10, 100, 1,000). Using a logarithmic scale helps us differentiate between low-impact and high-impact costs, preventing a single major cost from being obscured by a series of minor ones. Since it’s difficult to quantify costs to the exact value, the logarithmic scale accepts that we are dealing with estimates largely based on experience or short research (like 30 minutes or so).

Here’s an example:

AspectImplementation costInternal cost of wrong decisionExternal cost of wrong decisionInternal cost of no decisionExternal cost of no decisionData validation & sanitisation100010010010001000API Traffic routing1001010010001000API Deployment100100110001Logging and monitoring1010110001Scalability and performance optimization100101001010Caching1010101010

Using this scorecard, we can calculate a Research Priority Score for each aspect, helping us decide where to invest our discovery efforts. We calculate this by multiplying the relevant costs, which highlights where a wrong decision would have a significant negative impact.

By analyzing the scorecard, we can then apply the principles from our decision matrix:

• For aspects with a high Research Priority Score (like “Data validation & sanitisation”), we should treat them as Quadrant 2: Research & Validate. This is where we should invest in deep discovery, like collaborating with a UX researcher or creating RFC design documents for engineering feedback.

• To accelerate time to market, we should identify aspects with a high cost of no decision but a low cost of wrong decision. These fall into Quadrant 3: Decide & Act Quickly. For “API Deployment” and “Logging and monitoring,” the low External cost of wrong decision means we should quickly find a solution and move forward.

• Finally, we can find aspects with low costs across the board. These fall into Quadrant 1: Defer or Default and can be ignored for now. For example, “Caching” and “Scalability” both have relatively low scores, so we can defer these until they become necessary.

Applying the Framework to Everyday Coding

This cost-based decision framework isn’t just for high-level project planning; it’s a powerful tool for improving efficiency in our day-to-day coding too, primarily as a mental model rather than requiring a spreadsheet analysis. How often have you found yourself stuck trying to find the perfect solution to a problem, only to realize you’ve spent hours deliberating when a “good enough” solution would have unblocked you much faster?

Consider a complex function you need to write:

• Cost of Delay: Every minute you spend agonizing over the most elegant, highly optimized algorithm is time not spent delivering value. If the immediate need is to just get the feature working, the cost of delaying a functional solution can be high (e.g., blocking other features, missing a deadline).

• Cost of Wrong Decision: How bad would a less-than-perfect solution be? If it’s an internal utility that only runs occasionally with small data sets, the “wrong” decision (e.g., a slightly less efficient algorithm) might have a very low cost. If it’s a core performance-critical component, the cost of being wrong is much higher.

This framework encourages us to make pragmatic choices:

• Sometimes “Good Enough” is Best: If the cost of delay is high, and the cost of a slightly imperfect solution is low (e.g., it can be refactored easily later, or the performance impact is negligible for current scale), then choose a “decent” solution and move on. Don’t let the pursuit of perfection become the enemy of progress.

• Prototype for High-Impact Decisions: If you’re unsure about the best approach for a critical piece of code, don’t over-engineer upfront. Quickly prototype a few options. The “research and validate” quadrant applies here: the cost of delaying the final implementation is low, but the cost of getting the fundamental approach wrong is high. A quick prototype drastically reduces that risk.

• Prioritize Learnings: Often, getting a working solution, even if it’s not ideal, allows you to gather real-world data and feedback. This new information can then guide a better, more informed decision for future iterations.

By consciously applying this cost-based framework, software engineers can move beyond intuition, make more informed choices, and ultimately drive more successful outcomes for their projects and organizations. It empowers us to be not just technical contributors, but strategic problem-solvers.

Two Modes of Leadership

A staff engineer operates in two essential leadership modes:

1. Direct Leadership (The Hands-On Contributor)

This is the hands-on approach where your impact is immediate and visible. It involves solving critical problems, unblocking a team, or personally driving a project to launch. The connection between your effort and the business outcome is clear, making this a reliable way to get a measurable return on your time.

• When to Use It: To establish a high standard of quality, build team confidence by showing a path forward, or resolve a time-sensitive technical crisis.

2. Leadership by Proxy (The Strategic Influencer)

This is a more strategic approach where your impact is scaled through others. You design systems, define architectural standards, or mentor engineers. Your work enables others to be more effective, making the impact less direct but potentially much larger.

• When to Use It: To address systemic organizational or technical problems, define long-term roadmaps, or design systems that support years of future growth.

The challenge is that it’s easier to measure the expected return on investment (ROI) for direct leadership. You can often estimate the effort needed for hands-on work and see the immediate results. This makes it easier to avoid getting stuck in strategic work with little potential for a good ROI. However, being able to operate effectively by proxy is essential for achieving impact at scale.

Switching Between Modes

The ability to switch between these two modes is critical for most staff engineers. Ultimately, every decision should be guided by one question: where can you have the greatest impact? This applies to both short-term and long-term outcomes.

Once you’ve decided on your focus, act deliberately. A great place to start is your job description. Ensure it clearly outlines your primary focus and gets support from your manager and sponsors. For example:

• I will spend 80% of my time as a tech lead on project X to unlock a critical growth opportunity.

• I will spend 20% of my time in architectural design and review, noting that the impact of this work will likely take longer to see.

Next, focus on time management. There are two levels to consider:

1. Thematic Focus: To achieve effective outcomes, it’s wise to schedule work in themes that run for several weeks before you switch. This protects your focused time. For example, spend four weeks on Project X and then one week on architectural design.

2. Maintaining Balance: Even with a thematic focus, you still need to set aside time each week for tasks outside of your current theme—the “keeping the lights on” work.

Watch out for ad-hoc tasks, as they can quickly derail your plans. By using time management and scheduling, you can ensure you dedicate time to both modes and avoid neglecting the high-impact, long-term work.

Planning Your Time

Here is a sketch of how these two approaches might look on a calendar:

Week 1 (Project X Focus):

• Monday: 50% focused coding on Project X; 50% on weekly team syncs and ad-hoc requests.

• Tuesday: 100% deep work on Project X.

• Wednesday: 50% focused coding on Project X; 50% on mentoring and code reviews for other projects.

• Thursday: 100% deep work on Project X.

• Friday: 50% strategic planning for a future project (part of your 20% theme); 50% wrap-up tasks.

Week 5 (Architectural Design Focus):

• Monday: 60% on architectural design review; 40% on team syncs.

• Tuesday: 100% deep work on system design.

• Wednesday: 50% on architectural design; 50% on unblocking the Project X team.

• Thursday: 100% deep work on system design.

• Friday: 50% on a communication about the new architecture; 50% on ad-hoc requests.

Conclusion

Ultimately, staff engineering leadership is a dynamic skill, not a fixed role. The key isn’t to be one or the other, but to master the continuous dance between direct and strategic work. Embrace this challenge, because your ability to switch fluidly between immediate contribution and long-term influence is what will define your impact and leadership as a staff engineer.

This is an initial post covering the foundation on a high-level. In later posts I plan to dive deeper into the rationale of some practices listed.

Below is an opinionated list of practices that I would include as the baseline of a team. Of course each practice need to be reviewed based on current conditions to make sure they make sense.

Speed of learning, continuous discovery needs to be an integral part of any user facing development team. Team members need to understand the value of learning and how speed of learning needs to be prioritized. A bit simplified but; Is something good enough to uncover new learnings? => Release it

Outcome over output, a feature being released is sure something to celebrate but the aim of the team is to reach outcome. A released feature with no or unhappy users has little to no value.

No estimates, to avoid estimating functionality that we have already committed to building. There's value in estimating on feature/project level to iron out priority but after that we are only getting diminishing returns.

No deadlines, a product development team will not benefit from deadlines so avoid them. Only use deadlines when there is a high external impact that will happen if the deadline is not met.

Kanban, is for most product teams the more suitable way of structuring work. Some iteration cadence is still needed for planning and other ceremonies but what has been completed at the end of one iteration is not the goal.

"Off-board" time, many teams struggle with planning, refactoring and cleaning out tech debt. We know we need to take time to make technical improvements. With off-board time we make sure that a healthy level of technical improvements are always being done. I believe it’s easier for a Product Manager to commit to say 15% time on technical improvements instead of making a decision on a specific technical improvement.

Zero-bug policy, by setting a strict definition on what is a bug and what is an improvement. And, afterwards aiming to resolve all known bugs. This practice makes help us towards higher software quality and how a clear description for how to prioritize bugs.

Below is a collection of  books and resources that helped me kickstart the learn about leadership and engineering management.

Books

An Elegant Puzzle – Will Larson
My first choice for reading about engineering management.

Engineering Management for the rest of us - Sarah Drasner
Currently listening to this book. In contention as the first book to read when going into engineering management.

Five dysfunctions of a team - Patrick Lencioni
Works really well to listen too. You probably end up listening to this more than once. Really good for understand how to relate to your peers and other leaders in the organization I think.

Radical candor – Kim Scott
Understanding “Care personally, challenge directly” and always strive to approach leadership this way.

The Manager’s Path – Camille Fournier
Also a great book on engineering management. But a larger focus on management at different levels in the hierarchy.

Managing Humans – Michael Lopp
Maybe not the first books to read but if your like me (an example-based learner) this can help you see real-life situations.

The Art of leadership - Michael Lopp
A practical book on engineering management, director and executive leadership.

Articles

Engineering Manager archetypes

Mentor, coach, sponsor: a guide to developing engineers | LeadDev

Makers vs Manager schedule

Talks

I know I’ve watched a bunch of talk but memory is failing me so for now there’s only one talk linked. But do give LeadDev a follow on Youtube and you’ll probably find some topic supporting your growth.

The Engineer to Manager Transition, by Former Twitter Director of Engineering David Loftesness

With this post I try to express my current understanding of how to communicate expectations for Senior Engineers. I might to update this post as I learn and receive feedback.

About a year ago I moved from Engineering Manager to Staff Engineer at a time when the definition for the role was very vague. There was a career framework but a career framework would never be able to fully express what would be required of me. It meant that I was very much part of setting the expectations of my new role and doing so by building an understanding of how the role was defined in the wider software community. My goal with this post is to, in a condensed format, help guide Senior Engineers and Engineering Managers in discussion around Staff Engineer roles.

A bit of a disclaimer. There is a lot to say on this topic and many have written about it before, see links in resources. To make something more condensed I will make some assumptions to narrow down the scope. 

• Mid-size/smaller companies (say 30-70 engineers)

• Product Engineering makes up the majority of the engineers. 

• Primarily need for Tech lead and Architect archetypes 

Let’s first talk about the terminal level

Many companies use the Senior Engineer level as the terminal level, i.e. the level where the organization doesn't have expectations that engineers will move on to the next level. The reason to have a terminal level is because after level the expectations change a lot. What got you to be a Senior Engineer is most likely not what will get you promoted to staff+ roles. But remember that Senior Engineers are super valuable, for some staying and improving in this role is a much better fit for everyone. Most companies also express this by letting the salary band of Senior Engineer level reach well into the salary band of Staff Engineer level.

For an Engineering manager a good initial sign would be that the Senior Engineer shows interest in technical leadership and wider technical impact. If they are seeking promotion without showing interest the engineer might be much better off to keep improving/staying as a Senior Engineer.

Business impact over codebase impact

At a high level I think the change in expectations can be expressed as a stronger focus on business impact over codebase impact. Roughly, the Senior Engineer implements a new feature for teams to use and tell them through slack before continuing with other work. But the Staff Engineer will make sure that the functionality is getting used and making the teams more successful. Basically a much greater focus on outcome instead of output.

Technical skills are still essential but apart from the Solver archetype it will not be enough to reach the expected impact. The lever that enables the expected impact requires a whole lot of soft skills, i.e. ability to gain impact through others.

Expectations

I have come to realize that I think there are two sets of expectations that any engineer aspiring for Staff Engineer level should consider. There’s the expectations on what it will be like to work as a Staff Engineer and if you will enjoy it. And then there’s all the expectations from the organization before they are ready to promote you.

Expectations when being a Staff Engineer

Here’s a short list of what you can expect to be doing or experiencing as a Staff Engineer. I think it could be used as a starting point for anyone interested in the Staff+ levels. If you're still interested after reading this list I suggest picking up one of the books mentioned in resources.

• You own and continuously realign your job description

• You probably are involved in more than one initiative at the time. Some big, some small. 

• Prioritize your time and avoid snacking

• Problems are ambiguous in nature and it’s your job to bring clarity

• Effectively network to build organizational context

• Coach and mentor engineers towards increased productivity/effectiveness

• Imposter syndrome only gets worse

• Might write code but most often avoiding the critical path and seldom will it be the highest impact action that you can take.

• You are a leader and a role model

Expectations for becoming a Staff Engineer

As a Senior Engineer you will need to prove to leaders in your organization that you are capable of delivering the expected impact. That is what will finally decide if you get the promotion, trying to check boxes on a career framework will not get you there.

A way to show that you can deliver expected impact could be to have shown:

• Proven tech lead with sole technical responsibility for a team

• Ability to implement change that is not technical in nature. For example, successfully change how a team works with bugs

• Through a “staff project” shown that they have the required technical leadership skill. In most cases, showing ability to use soft skills together with technical knowledge to reach business impact.

Resources

Five Behaviours of Successful Staff Plus Engineers

Transitioning into the Staff+ Engineer Role - from Player to Coach

Senior Engineer to Staff Engineer

Staff Engineer: Leadership beyond the management track by Will Larson (Book)

The Staff Engineer's Path by Tanya Reilly (Book)

In this post, I'm focusing on API consumers that do not contribute data. I suggest that such API consumers will prefer an immutable schema API, meaning that the same request will provide the same data when requested at a different date and/or time regardless of preceding events in the system of the API.

Let's explore this characteristic with an example of two order systems, Impala has immutable characteristics, and Mantee has mutable characteristics. Both systems has public APIs that expose commerce order data.

Both APIs provide the endpoint with the single order schema outlined below:

api/orders?startDate=XXX&enddate=YYY

The endpoint would return an array or paging object but lets omit that to avoid a bunch of boilerplate.

Mantee Order Schema

{
	"orderId": 0,
	"orderItems" : [{ ... }	],
	"payments" : [ { ... } ],
}

Impala Order Schema

{
	"orderId": 0
	"events" : [
		{
			"items": [{...}	],
			"payment" : { ... }
		}		
	],
}

Note that the immutable schema in this post has only been constructed to be enough to explain the concept of this post.

Scenario

The Mantee and Impala APIs are consumed by a consumer that tries to sum up how much VAT was accumulated on each day.

1. At 10:30 on the the 11th of January a customer pays for an order of 100 pebbles and 100 books

2. At 9:30 on the 12th of January the customer they only need 10 pebbles so a refund with quantity of 10 is made.

3. At 18:01 on 13th of January the customer notes that an extra 10 books were not needed so 10 books are refunded.

For this scenario we will now explore what the order data will look at when making a specific request after each event above.

Requests at 11:00 on 11th

Mantee
GET api/orders?startDate=2024-01-11T00:00:00

{
	"orderId": 39,
	"orderItems" : [
		{
			"quantity": 100,
			"vat": 0.25,
			"amount": 33.92,
			"description": "pebble"
		},
		{
			"quantity": 100,
			"vat": 0.06,
			"amount": 40.00,
			"description": "books"
		}
	],
	"payments" : [
		{
			"id": "xyz",
			"timestamp": "2024-01-11T10:33:46Z",
			"amount": 8480
		}
	],
	"updated": "2024-01-11T10:33:52Z"
}

Impala
GET api/orders?startDate=2024-01-11T00:00:00

{
	"orderId": 39
	"events" : [
		{
			"type": "purchase",
			"timestamp": "2024-01-11T10:33:46Z"
			"items": 
			[
				{
					"quantity": 100,
					"vat": 0.25,
					"amount": 33.92,
					"description": "pebble" 
				},
				{
					"quantity": 100,
					"vat": 0.06,
					"amount": 40,
					"description": "books" 
				}
			],
			"payment" : 
			{
				"id": "xyz",
				"amount": 8480
			}
		}		
	],
	updated: "2024-01-11T10:33:52Z"
}

Requests at 10:00 on 12th

Mantee
GET api/orders?startDate=2024-01-11T00:00:00

{
	"orderId": 39
	"orderItems" : [
		{
			"quantity": 100,
			"vat": 0.25,
			"amount": 33.92,
			"description": "pebble" 
		},
		{
			"quantity": 100,
			"vat": 0.06,
			"amount": 10,
			"description": "books" 
		},
		{
			"quantity": -10,
			"vat": 0.25,
			"amount": 33.92,
			"description": "pebble" 
		},
	],
	"payments" : [
		{
			"id": "xyz",
			"timestamp": "2024-01-11T10:33:46Z",
			"amount": 8480
		},
		{
			"id": "abc",
			"timestamp": "2024-01-12T09:29:46Z",
			"amount": -424
		}
	],
	updated: "2024-01-11T10:33:52Z"
}

Impala
GET api/orders?startDate=2024-01-11T00:00:00

{
	"orderId": 39
	"events" : [
		{
			"type": "purchase",
			"timestamp": "2024-01-11T10:33:46Z"
			"items": 
			[
				{
					"quantity": 100,
					"vat": 0.25,
					"amount": 33.92,
					"description": "pebble" 
				},
				{
					"quantity": 100,
					"vat": 0.06,
					"amount": 40,
					"description": "books" 
				}
			],
			"payment" : 
			{
				"id": "xyz",
				"amount": 8480
			}
		},
		{
			"type": "refund",
			"timestamp": "2024-01-12T09:29:46Z"
			"items": 
			[
				{
				"quantity": -10,
				"vat": 0.25,
				"amount": 33.92,
				"description": "pebble" 
				}
			],
			"payment" : 
			{
				"id": "xyz"
				"amount": -424
			}
		}		
	],
	updated: "2024-01-11T10:33:52Z"
}

Requests at 19:00 on 13th

Mantee
GET api/orders?startDate=2024-01-11T00:00:00

{
	"orderId": 39
	"orderItems" : [
		{
			"quantity": 100,
			"vat": 0.25,
			"amount": 33.92,
			"description": "pebble" 
		},
		{
			"quantity": 100,
			"vat": 0.06,
			"amount": 40,
			"description": "books" 
		},
		{
			"quantity": -10,
			"vat": 0.25,
			"amount": 33.92,
			"description": "pebble" 
		},
		{
			"quantity": -10,
			"vat": 0.06,
			"amount": 40,
			"description": "books" 
		},
	],
	"payments" : [
		{
			"id": "xyz",
			"timestamp": "2024-01-11T10:33:46Z"
			"amount": 8480
		},
		{
			"id": "abc",
			"timestamp": "2024-01-12T09:29:46Z",
			"amount": -424
		},
		{
			"id": "def",
			"timestamp": "2024-01-13T18:01:46Z",
			"amount": -424
		}
	],
	updated: "2024-01-11T10:33:52Z"
}

Impala
GET api/orders?startDate=2024-01-11T00:00:00

{
	"orderId": 39
	"events" : [
		{
			"type": "purchase",
			"timestamp": "2024-01-11T10:33:46Z"
			"items": 
			[
				{
					"quantity": 100,
					"vat": 0.25,
					"amount": 33.92,
					"description": "pebble" 
				},
				{
					"quantity": 100,
					"vat": 0.06,
					"amount": 40,
					"description": "books" 
				}
			],
			"payment" : 
			{
				"id": "xyz",
				"amount": 8480
			}
		},
		{
			"type": "refund",
			"timestamp": "2024-01-12T09:29:46Z"
			"items": 
			[
				{
				"quantity": -10,
				"vat": 0.25,
				"amount": 33.92,
				"description": "pebble" 
				}
			],
			"payment" : 
			{
				"id": "abc"
				"amount": -424
			}
		},
		{
			"type": "refund",
			"timestamp": "2024-01-13T18:01:46Z"
			"items": 
			[
				{
				"quantity": -10,
				"vat": 0.25,
				"amount": 33.92,
				"description": "pebble" 
				}
			],
			"payment" : 
			{
				"id": "def",
				"amount": -424
			}
		}		
	],
	updated: "2024-01-11T10:33:52Z"
}

Summing up VAT

When consuming the Mantee API, we can match payments and order items as long as each event is processed when it occurs. Even if we need to correlate the order items with payments it works well in normal circumstances and when we are not interested in data in the past.

Notice what happens if we after the last refund tries to sum up VAT for each day. Since there's only one positive payment we can match with order items that are positive and get the correct result. For refunds abc and def we try to do the same but unfortunately the payments have the same amount.

While the same amount is one way the correlation becomes unreliable it is not the only one. Number of order item combinations or complex use of discounts could also be the source for correlation to be unreliable.

With Impala (the immutable schema), payments and items are grouped into events. For this reason working with events as they occur or far in the past will have no difference.

Conclusion

Mutable APIs lack reliable data handling for any consumer working with historical data. This becomes most prominent when the consumer tries to work with data that was produced before the consumer was activated to consume data from the mutable API. But in other cases it also lacks reliability that an immutable API provides. Imaging that a system is unresponsive and cannot handle incoming webhooks. While the system normally handles the example scenario when receiving webhooks on every purchase. It will during an outage be required to rely on risky correlation. With a growing number of integration the likelihood of being unable to correlate correctly will increase.

The conference proved to be a valuable experience, not only due to the insightful presentations but also because of the opportunity it provided for networking with fellow Staff+ engineers. I particularly appreciated how our host, Tanya, encouraged us to strike up conversations with individuals we hadn’t previously met before nearly every break.

There were numerous outstanding talks, but here are the key takeaways that resonated with me the most:

As staff+ engineers, we are expected to have a impact and influence that spans multiple product areas or even the whole company. That means scaling your self and one of the most effective way to scale your influence is through writing. Among the tools and tips presented, I found the advice to start with rough drafts and include a concise “tl;dr” (Too Long; Didn’t Read) section in documents particularly valuable. Lastly, I got pointed to the agile comms handbook which I recently read.

No StaffPlus conference would be complete without a discussion on time management. Staff Engineers must become adept at balancing maker and manager schedules. Understanding the business context is crucial for making the most of our limited time. The emphasis here is on managing our energy rather than just our time. This talk provided insightful strategies for tackling this challenge.

I been interested in system thinking for a while so I enjoyed the talk about systems thinking for software engineers. It points to system thinking tools that can be useful when diagnosing software problems or challenges. I really feel the need to try these tools because for me there is still a gap between the theory and seeing the tools used in practice.

Last presentation was actually then one matched my timely needs to most. I had been in the Staff engineer role for a little over 6 months and felt I didn’t yet have a process for setting goals and re-aligning with leadership. One of the keys ideas was finding a cadence for iterating on the goals on either a quarterly or 6 months schedule. It can’t be stressed often enough to avoid busy work and focus on high impact work. The way of setting up goals and mapping the to career level expectations in a spreadsheet seems very interesting. I later tried this approach and found it useful even it requires some decision making when an objective matches multiple categories. After some time I have also adopted the idea of making the goals publicly available as a document.

There was also plenty of interesting technical talks for example about running continuous migrations in an huge microservices environment. But instead of summarizing every talk I found it more valuable to focus on the topics that have direct impact for me to improve in my role. I must end with that I really enjoyed attending this conference. Even if you can see the talks online the networking component is a huge plus and I find the focus on the talks to generally be better when attending a conference.

Below is a collection of  books and resources that helped me kickstart the learn about leadership and engineering management.

Books

Radical candor – Kim Scott
Understanding “Care personally, challenge directly” and always strive to approach leadership this way.

An Elegant Puzzle – Will Larson
My first choice for reading about engineering management.

The Manager’s Path – Camille Fournier
Also a great book on engineering management. But a larger focus on management at different levels in the hierarchy.

Managing Humans – Michael Lopp
Maybe not the first books to read but if your like me (an example-based learner) this can help you see real-life situations.

Talking with tech leads – Pat Kua
Like previous books this is also a great one if you are an example-based learner. This books contains a large set of interviews with tech leads and gives good insight into how different tech leads have talked common challenges.

Other resources

LeadDev
Organization with conferences and community around engineering leadership. On Youtube you can find many great talks from previous conferences.

Pat Kua’s newsletter
Weekly newsletter that I’ve have learned a lot from. Also I thinks Pat is able to adapt the newsletter to time of year or what is happening in the world which makes you get relevant content when you need it.

Mycket hände 2018, minst sagt.

• Husägare

• Hund (Johannas)

• Bokio

• Tillbaka i USA efter 7 år

• Tävlingar i Sverige, Danmark och Norge

Året började med 4 bra träningsveckor men mest minnesvärd var förlovning med Johanna och helg i Norge. Jag väntade med vilovecka till vecka 5 då jag och brorsan drog till Garmish-Patenkirchen. Utmärkt ställe att ta sig till från både Göteborg och Stockholm (Bara flyga till München och sedan ta buss)

Fyra dagar spenderade vi där nere. Bra skidåkning, främst uppe på glaciären. Vi tog oftast det första tåget som gick till glaciären och åt frukost på vägen.

Sedan tuggade jag på med träningen igen. Även om det gick bra så var det inte lika lätt att få till långpass på den dagen jag jobbade halvdag. Så kändes det i alla fall. Men nu när jag kollar tillbaka så lyckades jag få till bra långpass hela vintern. Kan ha varit mer stress runt omkring för att lyckas med det dock.

En stor skillnad som startade ungefär i Mars var nyttjandet av Sweet spot intervaller (88-94% av FTP). Hade lyssnat mycket på “Ask a cycling coach” podcast och såg att den typ av träning skulle kunna passa mig. Mer om sweet spot intervaller senare.

Någonstans där i Mars så gjordes sig mitt andra intresse påmint. I ett par år så hade jag haft mycket fokus på cykling och mindre på mjukvaruutveckling. Jag började känna sug att ändra den balansen. Till en början var det inte helt uppenbart hur. Men när denna känsla infann sig så kände jag mig också redo för något jag inte varit redo för tidigare. Nämligen att ta steget att jobba på ett startup och vara med på resan att växa ett sådant bolag. Möjligheten har dykt upp då och då men jag har alltid känt att för att göra något sådant så behövs jag vara mer investerad än vad jag varit redo att vara. En helt personlig sak alltså, inget som någon arbetsgivare eller potentiell arbetsgivare tyckt.

Detta ledde till att jag hoppade på Bokio startat av en god vän och studiekamrat de första 3 åren på Chalmers. Man kan minst sagt säga att vi vet hur vi jobbar ihop. Att lämna iCore var dock inte ett lätt val. På iCore fick jag möjligheten att utveckla min tekniska expertis, stöttning i att bedriva elitsatsning och umgås med mycket fina kollegor. Speciellt tack till min chef Magnus som stöttade mig bra i att både vilja göra bra idrott och bra arbete. Att man väljer att jobba 90% behöver inte betyda att man inte vill mycket på sitt jobb.

Men nu lämnar vi jobb och fokuserar på träning.

Målet med 2018 var att ta UCI-poäng och köra så många UCI tävlingar som möjlighet. Majoriteten av tävlingarna var UCI tävlingar men något poäng lyckades jag tyvärr inte ta. Hade behövt lyft mig någon nivå mer för det, de pojkarna på banan är helt enkelt lite för bra.

Första UCI tävlingen var i Danmark. Var nog inte riktigt redo för farten på tävling. Avsaknad av tävlingsträningar med motstånd.

Två veckor senare bar det av till säter.

Därefter, vidare till Vårgårda.

Efter Vårgårda var vår tävlingarna slut för min del. Jag tänkte att fokus på tävling skulle vara bättre förberedelse för att tävlingar efter resa till USA. Idag osäker på om det var rätt men säker att det hade tagit för mycket energi att tävla vidare, börja på Bokio och förbereda för USA.

Att äntligen vara tillbaka i USA och ha med Johanna var årets stora höjdpunkt. Det var då 7 år sedan jag lämnade USA och Wyoming efter att ha jobbat där i ett år. Det var värt vara ända dag i sämre fysik och mer att åka ditt!

Jag tränade en del löpning i USA men som jag förväntat så krävdes en del arbete innan jag var i tillräckligt bra form igen. Jag jobbade hårt för att komma tillbaka i god fysik men väl i Falun på fjärde UCI-tävlingen så fanns det inte mycket power. Till veckan efter och SM så var det lite bättre men inte riktigt tillbaka.

Två veckor senare, 8 veckor hemma efter USA, så kände jag mig tillbaka. Vi drog nere till Kolding, Danmark för UCI Cat 1 tävling. Vilket race det var med största XCO startfältet jag varit med om. Tyvärr teknisk strul men annars ett helt ok race.

Nästa UCI tävling i Skatås med min egen klubb som arrangör.

Sista UCI tävlingen blev Karl XII ritet i Halden, Norge.

Är du kvar? Coolt, ja det blev ett långt inlägg när det är det ända för året

Lite av ett stople-ut år skulle man kunna säga. I alla fall vad gäller tävlingsresultat. Det finns två anledningar som kommer att jobba med 2019.

• Andningssvårigheter i varma dammiga dagar har blivit mer uppenbara. Presterar ofta bättre på hösten.

• UCI tävlingar tar ibland mycket energi i planering och förberedelser.

Jag har gjort en del framsteg också.

• Både hopp och dropp blir jag mer och mer säker på. Svåraste just nu har jag för hopp där jag inte har full känsla för fart och rörelse som krävs för dubbelhopp. I slutet av året började mindre dubbelhopp att sitta

  

• Uppnått ny max effekt på 1 och 2 minuter.

• Lärt mig mycket mer tävlingstaktik.

Jag skulle vilja skriva mer med det får räcka nu

Jag blickar nu framåt mot 2019. Av flera anledningar läger jag om träningen mot att vara tidseffektiv och fokusera på optimal prestation. Inte lika många långpass och istället många fler intervallpass i olika intensitet. Dessutom blir det fokus på tävlingar i Sverige och nära Göteborg. Kul att åka runt och tävla men det tog lite för mycket energi, förhoppningsvis lite bättre resultat istället.

Till sist, stort tack till de som stöttar mig främst Sportspec och BMC. Tack också till klubben jag tävlar för och alla fina medlemmar som många gånger stått med flaska eller hejat på tävling. Mest tack till Johanna som alltid finns där!

Det är en bra bit från Göteborg till Östersund så jag och Johanna drog iväg redan på torsdagen och sov i Orsa innan vi fortsatte. Ju längre norr vi kom ju mer fina höstfärger blev det.

Det är tämligen smidigt med tävlingsbanan i Östersund om man bor på Frösö Park hotell då målet är precis bakom hotellet. Så när vi hade checkat in och slappat lite så var det bara att ta cykeln och börja testa banan. Körde 3 varv med 10 min i hög fart, som vanligt även om jag la lite mer tid på att testa vissa partier. Det var speciellt några byggda hinder som inte var helt genomtänkta där det krävdes lite extra tid för att komma på hur man skulle göra.

När det var dags för start så behöll jag armvärmarna på men benvärmarna fick åka av. Även om det var ca 10 grader så vet jag nu hur varmt det blir när man kör på. Efter typ 2 varv så åkte dock armvärmarna av också. 13 stycken kom till start i Elitklassen så det var inte direkt trångt i starten. Det är kul ändå för den senaste tiden så har jag känt mig mycket starkare på första varvet. Ut på varv 2 så är jag i en grupp som kör om placering 5-9. Den gruppen håller sedan fram till 5e varvet av 6. Då jag ligger längst bak så tappar jag lite avstånd när farten höjs. Men kan ta mig ikapp en Nils Lillpers så det blir fight om 7e platsen. När det bara är den långa klättringen kvar så bestämmer jag mig att gå fram. Tyvärr har jag inte tillräckligt mycket krut för att köra ifrån. Försöker spurta men blir slagen med 1 sekund. Ändå väldigt nöjd med loppet, kör mot cyklister som brukar vara före mig. Tydligt att jag höjt mig en nivå till under hösten.

Träningsdata: http://tpks.ws/DdG2P

Plus/Minus lista:

+ Bra start
+ Bra startloop
– Släpper för mycket avstånd ibland
+ Bättre på att hålla fart i detta flacka uför.
– Taktik på sista varvet. Ska man gå ifrån i backe så måste man gå helt på max.
+ Vågade försöka att gå ifrån.
– Behöver inte ligga längst bak i gruppen hela tiden.
– Skulle sänkt tempot efter försöket att gå i från i backen för att kunna spurta bättre.

Lite om själva banan

Får ändå skriv lite om banan då SM närmast två år kommer går där. Tycker det var skillnad att tävla på denna bana i jämförelse mot att träna på den. Det första delen (första 4 min) är bra, det är inte så brant utför men för att hålla hög fart så får man vara vaken i kurvorna. Efter denna del så är det rätt mycket transport känsla på fram till dropp/hopp nr två bredvid langningen, det går lite nerför och lite utför men är inte så utslagsgivande. Första droppet får man verkligen hålla igen i annars landar bra långt ner, lätt fixat dock. Från dropp nr två så är det en rolig nedförslöpa där det längst faktiskt är lite rötter på stigen. Klättringen därefter är mer utslagsgivande upp till langningen. Sista utförslöpan är rätt ok den med men diket vid hoppet är problematiskt även om det går enkelt att köra om man landar innan och håller högt vänster. Där efter är det en ganska lång slakmota upp mot målet. Överlag så är det viktiga ett en del diken fylls (speciellt utför), att hoppen byggs rejälare och att man gärna fick leta upp någon mer stig med rötter. Varvets profil finns nedan.

Då tävlingen var på söndagen så åkte Johanna och jag ner på Lördag morgon så jag skulle kunna träna på banan mellan kl 15 och 17. Tävlingen gick i Vejle vilket ligger nästa 6 timmar med bil från Göteborg. Ett tips är att skaffa ett bropass när man skall till Danmark då man tjänar igen det på första tur/retur resan. Åker man dessutom mellan öarna i Danmark så sparar man ännu mer. Dessutom sparar man ju tid ;)

Även om det tog tid så gick det smidigt att komma till tävlingen. Efter lite parkeringsletande så böt jag om till cykelkläder och Johanna till löpkläder. Johanna drog ut på löppass medan jag drog till tävlingsarenan för att hämta nummerlapp. På tävlingar som denna är det ju obligatoriskt med nummerlapp under träning. Med nummerlapp på så drog jag ut på banan. Först ett lugnt varv för att kolla linjer och lära mig banan. På varv två så började jag med 10 minuter i tävlingsfart för att väcka kroppen. Därefter testade jag linjer i en utförslöpa som var lite lurig. Men efter att ha testat en ny linje så märker jag att jag tappar luft i bakdäcket. Då jag inte fyllt på med tätningsvätska så finns det inte tillräckligt mycket för att täta. Upptäcker när jag ska byta till slang att jag glömt slangen så bara att gå tillbaka till tävlingsarenan.

Väldigt glad att jag hade med mig extra hjul så jag kunde byta till det hjulet och kan köra slanglöst på tävlingsdagen. In i bilen och så åkte vi mot hotell via en rejäl omväg. Checkade in, duschade och åt middag på restaurangen. Därefter lite hotellrumshäng innan sovdags.

Söndag morgon är jag väldigt nöjd med. Då det var dåligt med p-platser nära tävlingsarenan så tog jag bilen de 1,5 kilometerna till tävlingsarenan innan kl 8. Ställde bilen på en bra plats och cyklade tillbaka till hotellet för att äta frukost. Efter frukost slappade vi på hotellet till lite innan kl 13 då vi begav och till tävlingsarenan. Sedan i vanlig ordning uppvärmning i 30 minuter och på plats för upprop 15 minuter innan start.

Utan UCI poäng eller Flammen liga poäng så fick jag starta långt back i det 45 man stora elitstartfältet. När starten går så går det till en början inte så fort som det brukar. En cyklist framför faller efter bara 300 meter men inga problem att passera. Ut på startloopen så är det inte så värst utspritt men snart så kommer det singletracks och så drar det ut sig naturligt. Blir lite förvånad när jag märker att jag får hålla igen utför när det är mycket hala rötter. Att bo i Göteborg och vara van att cykla när det är blöt och halt är inte så dumt. Som vanligt lite extra högt tempo första varvet men ganska tidigt så känner jag ändå att gruppen jag kör med har ett bra tempo.

Varv två så sitter jag mesta med i den gruppen jag är i. Några av de snabbast juniorerna kommer ikapp, tänker att dom ändå ska köra kortare och att det är bäst att hålla ett tempo som håller hela vägen. Det är just det som är det svåra denna dag. Startfält där jag inte vet vilken nivå åkarna håller samt att banan är av en karaktär som är lite olik det jag tävlat på i Sverige. Det är ofta väldigt branta backa följt av kortare utförslöpor. Ja det är mycket uppför och nerför i Sverige och men sällan så brant och så ofta. Ut på varv 3 så tappar vi några åkare och några går ifrån men fortfarande en grupp på 4 cyklister som ligger nära varandra. I sista långa backen så tappar jag och cyklisten framför på de andra två. Jag blir ombedd att gå fram och gör det med lite tveksamhet. Kör ändå på och ut på fjärde varvet så är jag ikapp gruppen.

Under fjärde varvet kommer vi ikapp någon till cyklist men på slutet av varvet så tappar jag en av cyklisterna. Ut på sista varvet så är jag typ själv. Jag gör ett helt ok sista varv om än lite långsamt. När jag passerar “feed zone” så gör jag hi-five med Johanna. Så kul att tävla på denna bana och med så bra konkurrens. Kommer i mål som 26:a av 45 startande.

Så här efteråt så tror jag att jag kunnat kört lite hårdare ändå men ser jag till normaliserad kraft (typ snitt för er som inte är pålästa i watt) så var det ändå det högsta på en XCO tävling på runt 95-105 minuter. Man kan ju tolka det som att jag har mer kapacitet nu. Det som inte syns här är stödet från Johanna under loppet. Hon står vid “feed zone” och ger mig varje varv alternativet att ta sportdryck eller vatten. Hon fyller även på flaskor då vi trodde det var 6 och inte 5 varv. Grymt!

Tävlingsdata: http://tpks.ws/Nj2Zq

Plus/Minus listan:

+ Bra start
+ Körde bra utför
– Svårt att veta hur hårt jag kan köra när det blir så många branta backar
+ Körde i mål med en väldigt positiv känsla
– När det var lite utför och bara grus så tappade jag
– Behöver lära mig hur hårt jag kan köra i backar utan att få kramp under ett race på 90 minuter.

RHCK mtb race

Med tanke på söndagens Swe-cup och UCI Cat. 3 tävling så bestämde jag mig för att köra taktiskt och inte köra allt för hårt. Lite förvånad att jag skrapat ihop tillräckligt med poäng i västgötacupen för att stå i första led men skönt att inte behöva slita så mycket under första varvet. Hittade ett tempo som passade mig fint och körde på så. Under femte varvet märkte jag att de bakom började närma sig men också kom närmare åkaren framför. När jag insåg att en pallplats stod på spel så höjde jag farten för att komma ifatt. Kom ifatt och kunde gå om precis innan vi gick ut på sista varvet. Valde att trycka på rejält när jag kom ikapp och sen efter några minuter kunde jag slå av lite på tempo igen. Kom i mål som 3a i Elit och 5a totalt. Kul att få komma upp på pallen

Plus/Minus listan:

+ Hyfsad start
+ Körde kontrollerat för att spara lite energi till dagen efter
+ Höjde farten på varv 4 för att bli trea i Elit (funkade)
+ Kul att få stå på pallen

Tävlingsdata: http://tpks.ws/egwaP

CK Master mtb race

Fjärde deltävlingen i Swe-cup och även ett UCI kategori 3 lopp. Extra kul med tävling på min hemma bana. Gjorde det jag tänkt efter SM och gick med det som är lite snabbare. Det funkade bra och under tredje varvet gick jag fram på slutet då jag kände mig mer säker på banan. Gruppen på 4 personer blev 3 men senare under varv 4 så insåg jag att benen inte skulle hålla hela vägen på den farten så släppte upp lite men inte så jag tappade massor. På femte varvet strulade magen en del och jag tappade fart, borde kunnat hålla 20 sek bättre tid på det varvet och ändå ha ben på sista varvet. Under sista varvet blev jag ikapp körd av Hannes Forsby och Nila Lillpers men orkar gå med. När vi kommer till den långa baken så tappar jag på en Hannes men får lucka till Nils. Håller luckan till Nils men orkar inte ta mig ikapp Hannes. Kommer in på en 12e plats med bara 1:25 fram till 8e placeringen.

Tar med mig att det här med att gå ut hårdare funkar. Jag gjorde med tanken på vilka jag hade bakom mig och nära framför årets bästa lopp. Men känner ändå att det går att göra ännu bättre. Bara att fortsätta köra offensivt!

Plus/Minus listan:

– Dålig start
+ Kunde ändå ta mig fram till bra position under start loop
+ Körde offensivt (vågade köra på)
+ Sänkte farten på fjärde varvet för att hålla hela vägen
– Femte varvet så sänkte jag farten för mycket
+ Kunde svara hyfsat när jag blev ikapp körd på sista varvet
– Magen var inte så glad i sportdrycken.

Tävlingsdata: http://tpks.ws/tjCDm

Likt förra året så gick SM i Värnamo även i år. Stora delar av banan var det samma men banan hade kortats av till 5 km och gjorts ännu mer utmanande teknisk. En mycket rolig bana som är utmanande både fysiskt och tekniskt.

Loppet i detalj

Kör en bra uppvärmning där jag som vanligt kör ett In Flames album i lurarna. Just detta album har jag snart laddat med i 10 år. Innan jag drar till upprop så häller jag rejält med vatten över mig då det var varmt. Väljer startplats så jag får yttervarv och när starten går så får jag en helt ok start. Det är lite lurigt att ta sig fram men har ändå en helt ok placering när vi kommer in på singletracks. Som vanligt så går det sedan fort under första varvet men dammar mer än vanligt. Efter ungefär 10 minuter så börjar placeringarna sätta sig och jag börjar ta mitt eget tempo. Blir omkörd av någon mer cyklist under andra varvet men fortsätter i det tempot jag satt upp. Det bildas en grupp framför mig som är ca 1 minut framför som jag länge ser men annars är jag mest själv. Varje varv så ser jag till att hälla vatten i nacken för att kyla av mig.

Under slutet på fjärde varvet börjar se jag en cyklist som släppt gruppen framför och som jag närmar mig. Det tar en bit in på 5 varvet innan jag kommer ikapp men när jag kommer ikapp märker jag att jag kan hålla ett högre tempo. Så när vi kommer till den branta backen vid arenan så ställer jag mig på pedalerna och gör ett ryck, högsta uppmätta effekt under 20 sekunder. Rycket funkar så jag får direkt lucka och kan distansera. Kommer ikapp ytterligare en cyklist lite senare på samma varv och kan gå om honom med.

Ut på sista varvet är jag själv igen men märker halvvägs att jag är på väg att bli ikappkörd av en som punkat under första varvet. Han kommer närmare och jag tar i mer för att hålla min placering. Kör på allt jag har och när jag kommer ut på gruset och med bara ca 200  meter kvar så inser jag att jag till och med lyckats dra ifrån. Kommer nästan ikapp en till cyklist som jag i mål bara är 12 sekunder bakom.

Träningsfil med varvtider: http://tpks.ws/izvI4

Plus/Minus listan (Med mycket plus)

+ Helt ok start
+ Jobbade för att komma fram innan singeltracks
+/- Tog mitt eget tempo efter 10 minuter. Kanske skulle ha försökt hänga med men kanske inte hade orkat lika bra då?
+ Kommer ikapp cyklist på varv 5, märker att jag är kör snabbare i skogen så står på hela stigningen vid arenan. Får direkt lucka!
+ Ser att cyklist, som punkat på första varvet, närmar sig på sista varvet. Ger allt jag har och lyckas på slutet av sista varvet dra ifrån.
+ Kör alla A spår
+ Langning med vatten och sportdryck. Tar jag inte flaska så häller jag vatten i nacke.

När vi ändå skulle till Småland så passade jag på att åka förbi Värnamo på lördagen för att kolla in SM Banan för XCO. Även om SM går på samma plats som förra året så var det än hel del förändringar så nyttigt att komma ditt och kolla in det tekniska partierna. Då väldigt många hotell var fullbokade så bodde vi i Vetlanda mellan Lördag och Söndag. Men att bo på stadshotell var inte så klokt då hotellet även agerade nattklubb. När väl musiken tystnat så fick jag ändå en god natts sömn.

Söndag morgon så åkte vi till tävlingen tidigt så jag kunde värma upp innan fållorna öppnades. Det funkade fint, fick 30 minuter uppvärmning där jag kunde kolla in det sista kilometerna av banan innan jag ställde in cykeln i fålla 3.  I och med att jag fick stå i fålla 3 så var det viktigt att stå långt fram så jag skulle kunna ta mig upp när starten gick.

När starten gick så var det bara att trycka på. Mycket folk att ta sig om men inte alls omöjligt att ta sig upp. Det tog nog ca 5 kilometer så hade jag kommit fram till en bra position. Därifrån handlade det mest om att hitta sin grupp. Tidigt kände jag vänster höftböjare var väldigt tight och att jag behövde vara smart för att inte dra på mig för mycket smärta i ryggen. I och med att det inte är något nytt så vet jag i alla fall hur jag ska hantera det.

Ut på den andra loopen så kommer vi tillslut till tekniska singeltrack både uppför och nedför. En cyklist går upp och jag går med som andra person. Vi kör på hårt uppför och utför och när vi kommer ut på grus så ser vi inte ens de andra. Vi bestämmer oss för att jobba ihop och fortsätta trycka på över singeltracksen. Det går bra men jag märker att höftböjaren blir värre och väljer att slå av lite på tempot och jobba med lite högre kadens. Det funkar men gör också att det går lite långsammare. Efter 10 minuter ungefär kommer en större grupp ikapp och då är det bara att åka med den. Det blir sedan mycket singletracks där det bara är att flytta med och spara energi.

När vi lämnar singeltracks delen mitt och kör mot avslutningsdelen men många stigningar så kommer Niklas Gustavsson från Team Tre Berg ikapp oss. Han dunkar på rejält på asfalten och jag bestämmer mig tidigt att inte gå upp och hjälpa till med dragjobbet. Stigningarna kommer och dumt att köra sönder benen innan. När vi kommer till stigningarna så klarar jag av att gå upp och köra med i stigningarna. Tappar dock en del på efter den sista stigningen och orkar inte köra ikapp. Vi blir en grupp på 4 åkare som börjar jobba ihop. Det blir ett bra samarbete och när vi har 5 kilometer kvar så går jag fram och börja köra på. Vi kommer ikapp några cyklister som släppte. Jag kollar inte bak så mycket utan köra på och tänker att det får visa sig om det gör någon skillnad. Med bara 500 meter kvar så inser jag att det flesta är kvar. Det blir spurt där jag inte har så mycket krut kvar och får släppa två cyklister förbi mig..

Kul att få till ett genomföra ett bra lopp som också var bra taktiskt. Sökande ett det perfekta loppet fortsätter dock men känns som det närmare sig.

Tävlingsfil: http://tpks.ws/dwSIA

Så här efteråt så märktes det att det var längesedan jag körde XCO. Det är helt enkelt svårt att veta hur ont det får göra för att ändå ha krut på sista varvet. Denna gång så hade det faktiskt kunnat göra lite ondare än vad det gjorde. Får helt enkelt ta i mer nästa gång.

På söndagen blev det socialt med sambon och intervaller istället för tävling. Ibland är det precis det som behövs!

Sammanfattning av loppet samt träningsfil:

+ Bra start med tanken på startposition
+ Smart kört med pulka baken
– Kunde ta i mer överlag på banan
+ Sitter tydligen väldigt bra på cykel nu
+ Har mer flytt i skogen än vad jag hade tidigare

(De två sista kommer från kommentarer efter tävlingen)

Trainingpeaks: http://tpks.ws/tyPhK

Foto: Markus Lidevi

På tävlingsdagen så kändes det ju i ryggen men inte så det störde på cykeln. Även om jag körde ett par varv dagen innan så körde jag några partier innan start då det regnat en del. Banan i Vårgårda för de som inte känner till den inkluderar två långa klättring uppför en slalombacke. Med totalt 6 varv så blir det rätt tufft men samtidigt så är själva banan rolig, iår ännu bättre än tidigare. När startskottet gått så hade jag inte tillräckligt krut i benen för att placera mig bra i första stigningen. Segt att vara långt bak men bara att jobba vidare. Jag tyckte jag kom in i en hyfsad rytm även om farten inte riktigt fanns där. Men så på 4e och ut på 5e så började det gör mer ont i ryggen och efter att ha gått i baken för andra gången så insåg jag att det var bäst att ge upp. Tråkigt men samtidigt klokt för att kunna vara i bättre slag till helgen efter.

På vägen hem så kom dock samma trötthet och huvudvärk som jag hade i Högbo tillbaka. Sån tur tänkte jag så hade jag ju redan bokat in massage till dagen efter. Men efter massagen så började jag känna av halsen och sen på kvällen så var förkylning ett faktum. Dubbel segt!

För att komma på banan igen så bestämde jag mig nu att inte köra tävlingarna i helgen utan sätta igång träningsperiod 2 lite tidigare. Försöker var lite smart nu och ge kroppen några dagar lättare träning innan jag börjar gasa. Även om det nu blir lite mer träningsfokus så kommer det bli en hel del tävlingar också. Det enda skillnaden att jag inte släpper upp träning lika mycket som inför de tävlingarna jag kört hittills. Några lätta dagar till sen trycker vi på för att bli ännu snabbare och starkare!

Klippingracet (Plac. 22)

På lördagen var det swe-cup premiär i Säter. En rolig bana som bjuder på bra många klättringar även om de aldrig är så värst långa. Tung i kroppen tyvärr men körde helt ok med det jag hade för dagen om man räknar bort första varvet.

+ Igång drag i starten - Dålig startloop - Tunga ben + Tekniskt bättre än tidigare år

Tävlingsdata: http://tpks.ws/m32Ul

mtbfoto.se

Högbobiken XCO (Plac. 14)

När man har dödsben redan från första tramptag så är det inte lätt att köra ett bra första varv. Att jag dessutom inte får i pedalen direkt gör ju det hela inte bättre. Men idag känns det tidigt att det är mer än benen som inte har den vanliga orken. Bestämde mig direkt att bryta inte var ett alternativ, denna dag var det annars många som valde det alternativet. Jag kämpade på med det jag den energi jag hade, tekniken var definitivt bättre än den varit tidigare år. Tidsmässigt är loppet ändå bättre än tidigare år vilket är positivt med tanke på att kroppen inte svarar som den borde.

+ Krigade mig igenom hela banan och tog poäng - Trött kropp + Noterar en del tekniska framsteg - Riktigt dålig start (Skärpning!)

Tävlingsdata: http://tpks.ws/iGIAr

Jakub Sarota

Hoppas nu att tröttheten släpper, högst sannolikt att det har med allergi eller liknande att göra.

Det började dock inte så värst bra i lördags. Kommer till tävlingen lagom till tiden då banan är öppen för träning. Kör i ca 4 minuter innan jag drar genomslagspunka i rockigare. Jahopp, tänker jag och sätter fart mot bilen för att fixa punka. Blir tvungen att sätta i slangen då hålet är för stort för att tätas av punkteringsvätskan. Drar i mer luft då jag inser att det kommer behövas mer luft för att undvika fler punkor. Så ut på banan igen. Kommer typ 2 minuter till sen hoppar jag lite för långt i det mindre hoppet och framdäck släpper från fälgen så att all luft åker ut.  Hade dumt nog bara en slang kvar så hann inte laga framdäcket innan träningstiden var slut.

Foto: Jonas Andersson

Sån tur var så har jag fina klubbkompisar som kunde låna ut en slang till mig. Jag drar i ännu mer tryck för här ska det inte bli fler punkor. Banan fick jag reka tills fots istället.

Sen flöt allt på som det ska. Fick en bra start och var 3a ut från startlooopen. Tyvärr så fastnade en cyklist framför mig i första backen så jag var tvungen att kliva av cykel. Väl uppe på cykeln så hade rätt många cyklister kommit förbi mig. Under de två första varven så blev det många att köra om och tyvärr hamnade jag bakom en del strul vilket gjorde att det tog längre tid att komma upp i fältet.

Från varv 3 så var det bra flow. Kunde köra på med bra känsla och plockade hela tiden placeringar. Men på sista varvet så kom jag inte så långt innan jag fick ännu en punka. Började springa med cykeln men det var långt till mål så jag valde att bryta då det kändes som det skulle slita för mycket på ena foten.

Tråkigt så klart att punka men jag fick i alla fall köra igenom loppet med en känsla av att kroppen är starkare än förra året. Till helgen är det dags för tävlingar igen, då blir det 3 dagar i rad :)

Tävlingsdata: http://tpks.ws/fNZn3

Summering:

+ Bra startloop - Fastnade bakom cyklist direkt på första varvet. Fick hoppa av cykel och blev då omkörd av väldigt många. - Mycket strul under första och andra varvet. + Hyfsat jämn fart över alla varven + Att jag återhämtar mig bra och kan köra fort med hjälp av hög kadens (100rpm) när det går. - Behöver öva mer syratålighet -- punktering på sista varvet -- Dubbla punkor när jag skulle testa banan, så han inte ens köra ett helt varv.

Igår satte jag den detaljerade planen fram till slutet på maj. Volym och träningsbelastning kommer succesivt att minska för att få upp en god form. Går allt som det ska så borde jag vara som allra snabbast i mitten av maj.

Jag har fortsatt med att göra mycket intervall träning, totalt fyra intervallpass även denna vecka. Det verkar faktiskt som att det funkar att köra intervaller 3 dagar i rad om man bara väljer rätt intervaller.

Något som däremot var sämre denna vecka var utebliven styrketräning. Det är fortsatt en utmaning för mig att hitta dagar där det passar. Antingen är det en lättare dag och då känns det som styrka skulle göra dagen för tung. Annars kan det vara en dag med intervaller och då vill jag helst inte köra styrka på morgonen och vara tung. Ska testa mig fram lite mer, kanske kan jag hitta en bättre tid än morgonen att köra passen på.

Att vara testobjekt för en studie om knäsmärtor för cyklister var dock höjdpunkten. Testet gick ut på att först göra diverse rörlighetstester. Därefter så sattes ca 40 bollar på kroppen som med hjälp av 3D kameror skulle kunna visa hur kroppen rör sig på en dator. Med alla bollar på plats så gjordes först utfallstegstester, där knäkontrol är väldigt viktigt. Sedan så satte jag mig på cykel och värmde upp i 10 minuter. Väl uppvärmd så började cykeltestet, 250 watt i 1 minut för att sedan öka med 50 watt för varje minut som gick. Med en höjning på 50 watt så tog det inte många minuter innan det blev riktigt jobbig och det inte fanns mer att ge. För mig som gillar teknik så var det extra roligt med 3D kamera tester. Ska bli spännande att se resultaten sen när analysen är färdig.

Siffror: TSS: 743.8 Total Tid: 13:09  timmar Styrka: 0 Löpning: 0:55 Cykel: 11:55 timmar

Träning: Måndag: löpning Tisdag: Mtb 3x7 min med GCK Onsdag: Mtb 4 x 90 sek + 20 min TT Torsdag: tester qualisys + 5x5 min mtb intervaller Fredag: Distans Lördag: Lvg 20 min Z4 + (2 min Z3.5/30 sek Z6)x8 Söndag: Vila

Jag har nyligen kört FTP test igen, denna gång ute. Då det var toppenväder ute så bestämde jag mig för att köra testet ut för första gången iår. Jag föredrar att göra testet ute då min trainer inte alltid tillåter mig att ha just den kadens som jag skulle vilja. Jag gjorde som vanligt när det ska köras FTP test ute. Tog landsvägscykeln hemifrån och styrde mot Lindome via Kållered. På vägen så körde jag två stycken 1 minut max. Väl nere på Hällesåkersvägen så satte jag igång FTP testet, ca 10 min efter sista max ettan. Kändes tyvärr som jag hade lite mer kvar när jag kom tillslutet av de 20 minuterna men det blev ändå rekord med 15 watt. Så träningen verkar gå åt rätt väg.

Det är mycket intervallpass planerade per vecka just nu. Och nästa alla intervaller i skogen då jag vill få upp farten just där. Det tar några passa innan man riktigt får in farten i skogen men känner ändå att jag börjar närma mig nu. Dessutom så har jag sett till att få ihop en hel del race träning. Senast i lördags så körde jag träningsrace med Göteborgs Cykelklubb. Och även om jag blev själv efter ungefär ett varv så hjälper det med flera ute på banan. Skulle man slappna och så kan man ju bli ikapp körd. Årets första crash hann jag dessutom med som man kan se på bilden nedan.

Just ikväll har jag varit på en föreläsning med Mikael Mattson. Riktigt intressant speciellt med hur stor skillnad det kan vara i prestation mellan att sova 8 och 10 timmar. Fick med mig en hel del nya tänk vad gäller träningsplanering som ligger i linje med det jag försöker med att planera och monitorera baserat på belastning istället för tid. Ska klura lite hur jag kan använda det framöver.

Kom ihåg att inte fuska med sömnen!