Dan Ubilla

You’re Only a Few Months Behind

2026-02-24T18:53:00+00:00

There’s an anxiety that’s creeping into software engineers lately. Models are shipping every other week. The software engineering tool everyone was talking about last month has been deprecated for something new. Engineers who have always maintained a running list of tech are now overwhelmed by the sheer volume of bullet points getting added to that list. Engineering Managers are trying to keep up both to help their teams and also to keep their own skills up-to-date.

I hear it in the hallways. I read it online. The feeling of being left behind by all the latest is nearly tactile.

But in the mess of new technologies and anxious feelings is the good news. You are only a few months behind. This is all only a couple of years old. The technology is uniquely nascent. And whatever was state-of-the-art a year ago has since been wiped away by something newer. The latest and greatest is building on itself. And the ground you feel slipping under your feet is actually slipping under everyone’s feet.

You’re only a few months behind. And when was the last time in your career you were only a few months behind?

…Everything Else Is a Task

2026-01-14T20:29:00+00:00

I’ve been talking to my LLMs a lot. I spin up an agent, we collaborate, and generally come out the other side with something useful. Over the course of hundreds — thousands? — of these conversations, my practices have oscillated. Sometimes I’m very precise, and I cut to the core. I know what I need, and I’m able to ask for it. Other times, I’m all over the place, and I prompt like a stream of consciousness. While the stream of consciousness can be helpful to root out the core, I ultimately get something faster when I’m precise. And I tend to be most precise when I know what’s the context and what’s the task.

The other day, I was working on a personal project. I found myself fully uncertain of what I wanted to build next. I mean, I knew what I wanted, only, when I went to write it out, my mental model was loose and rickety. As sentence piled onto sentence, I found myself asking: what is my ask? Do I know what I want to be built? Or am I asking for help to figure out what to build? I was quickly able to cut to the core and pivot to that ask.

Magically, when you focus on the ask, it becomes clear that everything else is context. By starting with my ask, I can draw the line between the context my LLM already has and what remains. And my immediate goal becomes to close that gap. “Ok, so here are some important things to keep in mind” is a great signal for my own mind on what else needs to be shared. The beauty of separating task from context: by writing the context you strengthen your own mental model, sharpen your ask, and get to the outcome faster.

When I last explored this a few weeks ago, I had my trio of markdown files: AGENTS, PRD, and BACKLOG. Those have exploded recently, but luckily, in a fairly organized manner. My AGENTS describes the how, the PRD describes the high-level what, and my newly-branded BACKLOG becomes the delta between the product today and the design in the PRD. On top of that, the commands and skills I’ve defined provide further context into how my agents and I should work with a lot of meta guidance on how to write to the PRD and BACKLOG as well as updating AGENTS, agents, skills, and commands. Again, it’s the clear separation of context and task.

So what have you written lately for your collaborators? Are you sharing context or scoping work? The distinction should drive the writing.

Loops

2025-12-22T20:08:00+00:00

Lately, I’ve been thinking a lot about one of my first programming lessons. I must have been 8 or 9, and I had picked up a VisualBasic textbook that was wedged firmly in the family bookshelf. The first exercise was programming a dot to move one space on a board on the screen. It was fascinating and wildly rewarding, but as you know, this story isn’t about moving that dot one space. This story is about the next lesson — how to move that dot again and again and again in just a couple more lines of code.

About a year ago, I spent a lot of time thinking about how to use LLMs. What are they good at? Where do I need that? It was a pretty daunting exercise to examine everything you’re doing and try to find the right job to be done. And while I did find a few use cases here and there, the models kept getting better. And I kept wondering what else I could be using them for.

It was only recently that I realized I’d fallen into a habit of creating loops for myself. In these loops, I’d use LLMs, learn something about them, then return to the beginning: use LLMs, learn something more. Each discovery pulled me back for another rep. Each time, I would push the boundary on what I did the last time. And after a number of reps, the broader system started to become more clear. This clarity then presented more opportunities to pull in and try LLMs in new workflows. The system became self-propelling.

I fell into two principles I adhere to:

When you’re uncertain, make moves that collect information.
Where possible, compound knowledge.

Create loops. If you’re a software engineer, solve a problem you see often. Push it to production where you can gather feedback. Then iterate, iterate, iterate. Start simple. Repeat. The old lessons prevail. Happy looping!

Everything is Text…

2025-09-10T21:13:00+00:00

I’ve been writing code with LLMs for nearly two years. I’ve tried all sorts of tools, pushed tools through every workflow. But the breakthrough wasn’t a new app or model or even a better prompt — it was the humble markdown file. Plain, portable markdown text. With LLMs, the game is in how you get your context to the model. And the more you treat as text, the more you unlock.

For all the slick features offered to get context to the LLM tool, the crux of it is: how do we canonize our mental model for the agents to act as precisely as we desire. And we canonize in markdown files. These markdown files — best practices, PRDs, todos — are all the lifeblood for agents. What’s the shape these files should take so I can integrate seamlessly with the LLM tools? And how could I decentralize and democratize the todos to be accessible from more devices?

And I landed on: what if it’s all text? What if it’s all markdown? What would it be like to fully bend to the form factor for which LLMs optimize?

So I settled on three files: AGENTS.md, PRD.md, and a TODO.md. Agents to describe the how. A PRD to describe the vision. These two are more stable. But Todo describes what’s happening next. It’s the most malleable and receives the most reads and writes. It needs to follow me.

While the markdown files were portable between LLM tools, they were stuck on my machine. This wasn’t so bad for the first two files, but the Todo was my workhorse. Then I had my a-ha moment. I use Obsidian as my notes app. It syncs markdown files across devices and to the cloud. So I took all of my side projects’ Todo files, moved them to Obsidian, and created symlinks from their original directory. Now I can update my coding agents’ next todos from my phone. And when I’m at my machine, they’re ready to be picked up. The context follows me, not the other way around.

When more of your work is text, the LLMs and the device syncing flow seamlessly. The dream of the always-on agent doesn’t have to be driven by tools or models. It’s about context. It’s always been about context. And that context is just text. We just need to move it where it needs to be.

You Are a Prism

2025-08-13T20:35:00+00:00

In his seminal High Output Management, Andy Grove captures a key management role: filtering information. Managers do this in two directions. As a manager, you take in organizational context and distill it down to the key pieces your team needs to be successful. Similarly, you take all the information your team is creating and distill it for leadership, your manager, and your peers. You filter information, sharpen it, and pass it along.

But information isn’t your only medium. You also deal in culture. Because you are a prism.

One of the strange parts of leadership is that you both lead the team and are on it. When someone asks you, “How is the team doing?”, they’re generally asking about your reports. But imagine two outsiders talking and one asks about your team. At that point, the team includes you. You’re Schrödinger’s manager — sometimes you’re on the team, and sometimes you’re not.

Most of the time this is inconsequential. But two failure modes occur in two distinct scenarios: you’re highly positive while your team is highly negative, or you’re highly negative while your team is highly positive. Let’s look at each.

When You’re High and the Team Is Low

First, imagine an org-wide process change: for every pull request created, the author must record a short video describing the change. “That can’t be so bad,” you think. “Besides, this will be good public-speaking practice.” But your team is seething. “This will slow us down!” “Who’s going to watch these anyway?” Your optimism is too far removed from your team members’ reality. If you present your rose-colored view, your teammates will not only reject it but also begin to lose trust in you.

When You’re Low and the Team Is High

Second, the inverse: you’re low; the team is high. From your vantage point, you see rocks they haven’t spotted yet. Your team members, now energized, are able to think beyond themselves. They’re observant. And they notice your distress. When they’re flying high and you’re in it, they attune quickly. Your distress becomes theirs, and your gloom about those rocks becomes a self-fulfilling prophecy.

So how do you manage these disparities? Remember: you are a prism. Reflect the energy that’s necessary, and absorb the energy that’s necessary, for your team to be successful. You also reflect your team’s energy back to the rest of the organization.

When you’re out of sync with your team, the goal is to triangulate where you are, where they are, and where you need the team to go. Then walk them there. Genuinely. Your team and your peers will spot inauthenticity quickly. Get there yourself first. Then you can show the way.

You are a prism. Reflect the light for your team.

Start with Your Feet and Look to the Horizon

2024-10-03T17:35:00+00:00

Having mentored and managed numerous Engineering Managers, I’ve often seen them navigating new, sometimes overwhelming, leadership challenges. Whether they’re onboarding onto an unfamiliar team, building a new team from scratch, or leading through significant changes like a shift in scope or a key team member leaving, the uncertainty can be daunting.

In all these cases, I share the same advice: Start with your feet, then look to the horizon.

Step 1: Start with Your Feet (Now)

As a new EM, you’re faced with a series of immediate challenges. A team is looking to you for direction, asking questions like:

What are we working on?
Why is it important?
What are we building toward?

In these moments, I encourage EMs to start with their feet. Mentally picture yourself focusing in on the ground at your feet. Everything else washes away. What are the things the team needs today?

Tactically, I recommend EMs start with the backlog. When your team comes in on Monday, do they know what they should be working on? If the answer is anything less than a confident yes, start here. Your goal is to ensure there’s a well-defined, actionable sprint’s worth of work ready to go. Creating a backlog is the first step in establishing clarity and momentum.

Step 2: Lift Your Gaze (The Next Sprint)

Once you have the a sprint of backlog set, picture yourself slowly lifting your head just a little. You’ve handled the immediate, but what about the next sprint? If it takes you a sprint to prepare a sprint’s worth of work, your next step is creating the space for you to think further ahead. Begin by asking: what can I delegate from my sprint-to-sprint activities to that will free up my time for longer-term thinking?

Start small. Hand off certain responsibilities — backlog grooming or sprint planning — to a tech lead or senior engineer. Then look bigger. Can you delegate building a domain-focused chunk of the backlog to a team member? At tha point, you’ree starting to create some self-sustaining momentum.

Step 3: Look to the Horizon (Quarterly & Beyond)

As the team puts together sprints without your direct interaction, you can start looking further out. It’s time to think in quarters or even longer.

Start by asking:

Can the team set and work toward quarterly goals?
What major projects or initiatives are likely six months out?

The key here is that fidelity of the planning doesn’t need to be high — after all, you’re looking at the horizon, not examining every step. This longer-horizoned thinking is essential, but it’s a gradual process, one that only becomes possible once the immediate sprint work is stabilized.

By following this stepwise approach—starting with the immediate needs and gradually lifting your focus—you’ll build both confidence and clarity for yourself and your team. In times of transition, keeping this framework in mind ensures you’re able to balance short-term tactical execution with long-term strategic vision.

Remember: start with your feet, then slowly look to the horizon.

Push vs Pull Learning

2024-08-14T07:35:00+00:00

As a software engineer, you’re always in learning mode—whether it’s a new tech stack, a fresh codebase, or an unfamiliar domain. When someone on my team is onboarding to something new, they often ask me, “What’s the best way to get up to speed?” The answer varies, but I find it helpful to discuss two key approaches to learning: push learning and pull learning.

Push learning is when you’re fed material to learn. Imagine picking up a textbook, starting at chapter one, and steadily making your way through the book. Or maybe you’re watching a lecture series on YouTube, moving through each video in sequence. Here, you’re absorbing what’s being given to you, which is great for gaining broad knowledge and understanding theoretical concepts.

Pull learning, on the other hand, is more targeted. Picture a problem set in front of you—pull learning involves diving into resources as needed to solve the issue at hand. At work, this might mean watching a specific lecture to tackle a particular problem. Pull learning is all about learning by doing, which tends to make the material stick.

When you’re onboarding, blending both styles can be incredibly effective. The ratio depends on your siituation. One common consideration is how quickly start contributing. You may choose more push learning to optimize for a longer time horizon. If quick wins are crucial, more pull learning might be in order.

Another important consideration is the risk of not being fully ramped up. If you overindex on pull learning, you will only encounter things that are immediately relevant, which could leave you unprepared for rare but critical challenges. In other words, if a critical piece of your infrastructure rarely goes down, you won’t know much about it until it’s too late. That’s where push learning comes in — it helps you cover the unknowns.

By default, I encourage people to begin by applying pull learning and introducing some level of push learning to start. A great question to check your investment levels: “If I push learn at this rate, how long will it take to learn the material? And “Is that rate acceptable given the criticality of the key pieces of onboarding?” This reality check usually nudges people a bit more toward push learning

Keep in mind, push learning can and should be adjusted. If there are certain parts of the material that are more critical, you can and should get to them first as a part of your push learning. This form of push learning when the push learning is prioritized without being just-in time can be referred to as spread learning, and its inverse is referred to as scatter learning.

Bring this mental model to your next onboarding conversation. Happy learning!

A Portfolio of Work

2024-08-06T08:28:00+00:00

At any level of engineering, you are responsible for some work. Early in your career, it’s a ticket, a task. The work is narrow but likely deep. As you grow in your engineering leadership career, your purview becomes broader. And at some point, you’re no longer responsible for one thing. You become responsible for a collection of work. We call this a portfolio of work. Your portfolio of work and how you manage it constitute the impact you can make. And the further along you get in your career, the more nuance exists in how you can manage it.

Progressing from being responsible for one thing to many starts at the large project level. If you lead a project, break down the work into parallel pieces, and have teammates contributing, congrats — you have a portfolio of work. This is your first real experience managing a portfolio for the outcomes you desire. Initially, your project might be tightly scoped, but as the scope grows, so will the unknowns. You’ll begin to manage risk in how you approach the project and allocate work. This is your first real taste of managing a portfolio of work.

If you are a tech lead or engineering manager, you are responsible for the team’s outcomes. You’re now managing a portfolio of work across a team. At its most basic, you can manage each project separately to success. But as you gain experience, you can begin to manage the whole as a portfolio. Here are some important questions to ask: Which of the team’s projects do I expect to deliver the majority of expected impact? If a project was at risk, which project would I deprioritize to increase the chances of success? What does the curve of success for each project look like: is it binary or is it linear? Having these mental models can allow you to manage your work for greater impact.

As you grow comfort in managing your portfolio, the next step is to build in an intentional amount of risk. If your team has the capacity, you can begin to organize your portfolio to take on a moonshot: book 60% to “sure thing” work, 30% to “somewhat risky but linear impact” work, and push the remaining 10% toward that home run shot.

Once you manage your quarterly and half year planning well enough, you can intentionally manage your portfolio with time as an added dimension. Set your team up to deliver for a couple quarters in a row, and take the big home run swing once you’ve banked some gains. Or, if you took a swing and it didn’t come through, plan for more “sure thing” work the following quarter. Your portfolio of work exists in a given quarter or half year as your work-in-progress. It exists in hindsight as your team’s reputation. Build up your team’s social capital and spend some of it.

Finally, there’s breadth. As you work across teams, you begin to manage portfolios of portfolios. To do this with intentionality, you need to work with your team counterpart. Encouraging people and teams to take on or off risk becomes a part of your calculus. Two failure modes to consider. In one, teams are continually risk-averse and you need to push one toward risk. In the other, all of your teams are too bold, and you risk little delivery across them. As you manage your teams, manage them to produce the portfolio of work you intend across their breadth.

How’s your portfolio of work performing? What can you do this week to build some more intentionality into it?

Stop Repeating Yourself with the Rule of Three

2024-06-09T08:56:00+00:00

It’s Monday. You organize your day, and you double-check your calendar. You go to your first 1:1. Your team member asks why the team is changing your product’s strategy. You share your thoughts. Now it’s Tuesday. You have a 1:1 with your designer who asks the same question. You share your thoughts. Now it’s Wednesday, you meet with your TL who asks about the changes in product strategy. Congrats! You’ve just hit the Rule of Three.

The Rule of Three states that anytime you repeat yourself three times, you should have written it down at the start. By documenting your thoughts rather than repeating yourself, you’re creating leverage in your time. You save yourself the time of reiterating the same information, and you save your team’s time from having to hear and respond to your answer in real-time. This allows for deeper, more meaningful conversations. If your team member can read, digest, and clarify your mental model asynchronously, the two of you can have a richer conversation when you meet in person.

When you hit the Rule of Three, write it down immediately! It’s tempting to think, “I’ve already explained this multiple times; no need to write it now.” However, if you’ve had three conversations, there’s a good chance a fourth and fifth are around the corner. Plus, providing a written reference allows the first three folks to reflect on your mental model at their own pace.

How to Implement the Rule of Three

Take a Mental Tally: Take note when yourself repeating yourself. No need to be rigid here. When you’re in a 1:1, loosely, mentally note when you’re hearing a question a second or third time.
Reflect Post-1:1s: After each 1:1, ask yourself if there’s anything you should have shared earlier and if anything should be communicated more broadly now.
Proactive Documentation: Begin your Monday by scanning your calendar. Anticipate 1:1 topics and document your mental model in advance. While you won’t proactively catch all questions that will come up, the act of anticipating fosters empathy and preparation.

Practical Tips

Choose Your Medium: Whether it’s an email, a document, or an internal wiki post, pick a medium that’s matches your team’s culture of communication and importance of the message you intend to share.
Use Tools: Consider how your team expects to hear these updates. It could be an Asana message, a Slack message or an email. Again, match the means of communication to the team’s culture and the message.
Be Concise and Clear: When writing, ensure clarity and conciseness. Bullet points, headings, and summaries can help make your message digestible. Add a tl;dr at the top if you find your message is longer than two paragraphs.

So, go ahead. Start your next week and start counting. See how quickly you get to three, and then write it down. Your future self and your team will thank you.

As We Know It

2024-06-01T08:28:00+00:00

The value of software is largely driven be two factors: productivity gained and distribution. These can be considered as depth and reach. Over the years, distribution has shifted from on site to box to over the wire. And each has led to incentive shifts as the benefits of software became democratized through these increasingly pervasive distribution channels

Software productivity gains have gone through similar step function changes. Where once we wrote machine level code, we now write more human readable languages. These abstractions have made writing software more accessible with each evolution. And as access grows so do the number of people writing software.

Over a longer horizon, capitalism is a growth machine. And while the shape of scale of software will change, its growth is enabled through the shift change in LLMs we experience today. Software isn’t ending. It’s only ending as we know it. As it’s done before.