Kevin Hoyt

Managing Tech: 1:1

2026-03-23T00:00:00Z

This is part of a series:

Managing Tech: People
Managing Tech: Heroes
Managing Tech: Professionals
Managing Tech: Time
Managing Tech: Cadence
Managing Tech: 1:1 (you are here)

If you read the post in this series about meeting cadence and felt overwhelmed, I get it—it is a lot. In this post, I will dial it back and return focus to the people. As I have said before, without people, there is no manager. Making people heroes should be a primary goal of your leadership style. Let us focus on the people, and how to make them heroes. It starts with the 1:1.

What Is a 1:1?

The 1:1 meeting is exactly what it sounds like—a one-on-one meeting between you and one of your direct reports. On the surface, this sounds easy. You set up a meeting, show up, and talk about what is going on at work. Congratulations—you are halfway there. You are also halfway off the rails.

If you show up just to talk about the business, then you are missing the point of the meeting in the first place: the person.

One-on-one meetings should be people-focused, not operationally focused.

The First 1:1

When I get a new team or a new team member, my first one-on-one meeting is a little different from the ones that follow. At this point, we do not know one another yet. It would be presumptuous to launch into operational behavior.

You only get one chance to make that first impression. You can never have your first one-on-one again.

I may have handoff notes from a previous manager, but those come with bias. The direct report may have heard about me from others, but again, bias and hearsay shape that perception. The place to start, then, is to get to know one another.

When scheduling the first one-on-one meeting, include a general outline of what you will cover. As a rule, never send a blank meeting invite. In this case: introductions, what is working, what is not working, what they want from their employment, and their contact preferences.

Introductions

I generally start my first one-on-one meeting with introductions. To remove social pressure and give the person time to consider how they want to introduce themselves, I begin. It gives the direct report a pattern to follow.

I start with my broader industry experience—how I got here. Then I move to my experience within the company (if any). From there, I talk about my leadership style and expectations. I close with a few personal notes—where I live, why I chose to live there, my family, a book I am reading, or a movie I recently saw.

Then it is their turn.

This differs from a casual conversation in one key way: you should take notes. The facts the individual chooses to share are important to them, and therefore should be important to you. When ideas matter, you write them down. This is how they present themselves—the narrative of their work life. The only bias here is their own, and that is the bias you want to understand.

Let us say you hear that a direct report is into Star Trek. Capturing that detail may help you form analogies later. Imagine saying, “You know when Captain Picard did…”

What Is Working?

Now that you know a bit about each other, you can start building a broader narrative. I like to be direct here and ask what they think is working in the business today.

This gives the direct report space to express positive thoughts and emotions, and it helps establish an authentic relationship. Again, take notes. These are cues for what not to disrupt in your first 30 days.

If this is a new employee, you can still ask this question. You might focus on the hiring or onboarding process—useful input for improving how you build your team. You can also ask what they liked at previous employers. If something worked well before, it may be worth exploring.

What Is Not Working?

Now comes the harder pivot—what is not working.

Depending on the seniority of the direct report, you will get different levels of depth. Again, take notes. These are potential action items.

If a direct report is frustrated day after day but does not tell you, you miss your first opportunity to help them succeed. Some processes exist for good reason, in which case it is your job to investigate and report back. If they are broken, you can begin charting a path toward improvement and communicate that plan.

To be clear, what you are hearing is: “This is how you can make me a hero.” Do not squander that opportunity.

If this is a new employee, you can still ask this question. They likely left their previous role for a reason. Understanding those reasons can help you avoid repeating them. What brought them to your team?

Contact Preferences

Not everyone prefers the same communication style. Some want meetings. Others prefer email or chat.

Take time to understand their preferences, and share your own. For example, I let employees know that regardless of how they contact me, they can expect a response within 24 hours. It may not be a full answer, but it will be a response. I also expect the same in return.

This shared understanding is critical.

Your direct reports know how they work best—when they are most productive and under what conditions. Respect that. Interrupting deep work with urgent messages can break that productivity.

Since this is your first one-on-one, you likely scheduled the meeting based on what worked best for you. That is fine. Close by asking what time they would prefer going forward, and schedule the recurring meeting together.

A Word on Notes

You should always take notes in your one-on-one meetings, and those notes should be shared with the direct report.

This allows the employee to see how you interpret their communication. The shared document should be linked in the recurring meeting invite. As topics arise throughout the week, add them to the document so both of you can prepare in advance.

This approach creates a clear history and progression. Nothing is left to guesswork. Transparency builds trust.

When performance reviews come around, you both have a record to reference. In cases where performance coaching is needed, that history becomes even more valuable.

These notes should remain confidential between you and the employee. You can summarize themes when needed, but the document itself should remain private.

The Heart of the 1:1

Before going deeper, it is important to have the right mindset: 1:1 time is employee time.

While you may have updates, this time should be focused on the individual. Team meetings are for broader communication.

The structure of your 1:1 may evolve, but a useful starting point includes wellness, readiness, obstacles, recognition, and feedback.

Wellness

Think of this as work-life balance.

There is no need for employees to share personal details, but giving them the option matters. In some cases, serious issues may surface. You are not HR, and you are not expected to solve everything, but you are there to listen and guide them toward appropriate resources if needed.

You also need to ensure psychological safety. Not everyone participates in meetings the same way. Some may want space to speak, while others may prefer not to be put on the spot. There are no bad questions, and no one should feel humiliated or ignored for speaking up.

Watch for signs of burnout. If someone is consistently overextended, the 1:1 is where you catch it and correct course.

There will be times when extra effort is required. Make sure balance returns when those periods pass.

Readiness

I like each direct report to have one to three personal goals. These should be reviewed regularly.

Sometimes goals need to be adjusted. Sometimes they are not the right fit. That is fine.

These goals should align with where the employee wants to go and what the business needs. Finding that balance takes time.

Consider the SMART framework: specific, measurable, actionable, relevant, and time-bound.

Once goals are defined, make sure the employee has what they need to succeed. This may include training, mentorship, tools, or additional support. Your role is to identify gaps and help close them.

Obstacles

Where readiness is broad, obstacles focus on the present.

What is slowing them down right now?

If they are blocked by another team or process, step in. Your role is to bridge those gaps. These become your action items to track and resolve.

The outcome may not always be what you expect, but addressing obstacles improves the system for everyone.

Recognition

After the heavier topics, this is my favorite part of the conversation.

What has your direct report accomplished that they feel good about?

Celebrate those wins. If they do not have one, share what you see.

Recognition does not have to be limited to work. Personal achievements matter as well. There is far too little praise in the world—take the opportunity to add some.

Keep recognition shared in 1:1s confidential unless given permission to share more broadly.

Feedback

This is uncomfortable, but necessary.

How are you doing as a manager?

Feedback should go both ways and should happen regularly. When performance reviews arrive, there should be no surprises.

Taking feedback well takes practice. Avoiding it only creates problems later.

Tuning the 1:1

Over time, you may adapt your approach.

During my time at Amazon, these principles evolved into a more structured format aligned with broader business conversations and expectations.

Improving the 1:1

The 1:1 belongs to the employee. They should feel comfortable rescheduling when needed.

Preparation matters. Review your notes before the meeting. Form a point of view. Update the document in advance when appropriate.

Know the details. Be aware of time-off balance, training requirements, and upcoming milestones.

I typically schedule 30-minute 1:1s, but I leave buffer time afterward. Nothing signals that someone is unimportant like rushing out of their meeting.

Next Steps

The one-on-one meeting is likely your most important meeting of the week.

These conversations will generate action items beyond your day-to-day work—and that is the point. This is how you help people become heroes in their careers.

Take the time. Make the time. Be prepared. Keep shared notes. Build trust. Make heroes.

Quilt GPT

2026-03-21T00:00:00Z

My wife, Marna, has always been into arts and crafts. Her mainstay is crochet - which I got her "hooked" on shortly after we were married. Hats, mittens, scarfs, and sweaters. Afgans/blankets. She has shelves of amigurumi plushes that she has made. The list goes on and on.

Marna is also very capable with a sewing machine. While she will be the mom to sew on club patches for everbody, she can also make full costumes. We once went on a Disney Cruise that sailed during Halloween. Passengers were encouraged ahead of time to bring costumes. Marna turned us all into authentic pirates.

And then there is quilting. Quilts are emormous projects. They require numerous squares to be made - this can be a project unto itself depending on the complexity of the squares. The squares get sewn together. Then there is the padding. Then the backing. Then the edges. Then the quilting itself. Because of the effort, quilting projects happen far less frequently than other types of projects.

If you get a Marna quilt, you know you are loved.

Recently, Marna set out to make a quilt for her mother. The dimensions of this quilt are 8 squares by 9 squares, with each square measuring about 10 inches square. There were seven types of squares - squares with different patterns. Once she had all the squares created, it came time to figure out how to lay them out in a pleasing manner. With 72 squares, across 7 different square types, in an 8 (even) by 9 (odd) rectangle, this became quite the challenge.

The Challenge

Marna arranged the squares out in a random 8x9 grid on the floor of our living room. Then she asked for input. First from my daughter, whose brain attempted to make a pattern out of the chaos. Patterns are pleasing, right? Then came my turn, and my initial instinct was to do the same thing - force a pattern out of the noise.

After moving squares around for a while, we could not arrive at a pattern that was pleasing to the eye. Every way we looked at it, our brains would latch on to the partial patterns that were there, and expect them to continue, only to be jolted by the pattern ending abruptly. Then Marna mentioed that she was originally going for a random pattern, and my brain immediately jumped to the probability machines that are LLMs.

The Prompt

Trying to come up with a random pattern where none of the squares of the same type were touching would have taken us ages. Chat GPT however, could iterate extensively and find a pattern for us.

I am making a quilt. 
My quilt is 8 x 9 squares. 
For the individual squares, I have the following count of each. 
Make an 8x9 array in which none (or as few as possible) of the same squares touch. 
=== 
Flowers: 12 
Plaid: 12 
Squares: 12 
Spades: 12 
Dark Green: 11 
Mixed: 11 
Light Green: 2

The prompt starts with basic context. Dimension are added in, and then a reference to the types of squares. After that the specific task/outcome is specified. Finally, the actual square labels and counts for each. The squares are labeled using words that we as humans understood referenced the patterns on each of the squares.

The first prompt for this task described one of the square types as "Two by Two" which Chat GPT seemed to read as a number of squares, not as a label. It then proceeded to drop other square types entirely to make the count fit the dimensions.

The steps Chat GPT went through to come to a successful conclusion are as follows:

Exploring grid arrangement: Reviewing the count, dimensions, and labels.
Pattern arrangement: Pattern based on a Latin rectangle - then deciding to use Python.
Python: It then proceeded to write a Python script - and run it - to achieve the results.
Checking work: Chat GPT then checked the work/output, and found it lacking.
Update the code: Try again with some Python for edge cases of touching diagonals.
Verify the output: Successful outcome.
Present the results: In an inline table format for humans to follow.

In case you are interested, here is the 175 line Pyton program it used.

from collections import Counter
import random, math, itertools, time

rows, cols = 8, 9
counts = {
    'Flowers':12,
    'Plaid':12,
    'Squares':12,
    'Spades':12,
    'Dark Green':11,
    'Mixed':11,
    'Light Green':2,
}
labels=list(counts)
cells=[(r,c) for r in range(rows) for c in range(cols)]
# initial fill random
arr=[]
for k,v in counts.items():
    arr += [k]*v
random.shuffle(arr)
grid=[arr[i*cols:(i+1)*cols] for i in range(rows)]

orth_dirs=[(1,0),(-1,0),(0,1),(0,-1)]
diag_dirs=[(1,1),(1,-1),(-1,1),(-1,-1)]
def score(grid, diag=False):
    s=0
    for r in range(rows):
        for c in range(cols):
            for dr,dc in [(1,0),(0,1)] + ([(1,1),(1,-1)] if diag else []):
                nr,nc=r+dr,c+dc
                if 0<=nr<rows and 0<=nc<cols and grid[r][c]==grid[nr][nc]:
                    s+=1
    return s

def optimize(diag=False, max_iter=300000):
    arr=[]
    for k,v in counts.items():
        arr += [k]*v
    random.shuffle(arr)
    g=[arr[i*cols:(i+1)*cols] for i in range(rows)]
    best=[row[:] for row in g]
    bests=score(g,diag)
    s=bests
    T=2.0
    for it in range(max_iter):
        # pick two cells swap
        r1,c1=random.randrange(rows),random.randrange(cols)
        r2,c2=random.randrange(rows),random.randrange(cols)
        if (r1,c1)==(r2,c2): continue
        if g[r1][c1]==g[r2][c2]: continue
        old=s
        # local delta brute
        affected={(r1,c1),(r2,c2)}
        neigh=set()
        for r,c in list(affected):
            for dr,dc in orth_dirs + (diag_dirs if diag else []):
                nr,nc=r+dr,c+dc
                if 0<=nr<rows and 0<=nc<cols:
                    neigh.add((nr,nc))
        region=affected|neigh
        def regscore():
            tot=0
            dirs=[(1,0),(0,1)] + ([(1,1),(1,-1)] if diag else [])
            for r,c in region:
                for dr,dc in dirs:
                    nr,nc=r+dr,c+dc
                    if 0<=nr<rows and 0<=nc<cols and (nr,nc) in region:
                        if g[r][c]==g[nr][nc]:
                            tot+=1
            # edges leaving region need count only from region endpoints
            for r,c in affected:
                for dr,dc in dirs:
                    nr,nc=r+dr,c+dc
                    if 0<=nr<rows and 0<=nc<cols and (nr,nc) not in region:
                        if g[r][c]==g[nr][nc]:
                            tot+=1
                for dr,dc in [(-1,0),(0,-1)] + ([(-1,-1),(-1,1)] if diag else []):
                    nr,nc=r+dr,c+dc
                    if 0<=nr<rows and 0<=nc<cols and (nr,nc) not in region:
                        if g[r][c]==g[nr][nc]:
                            tot+=1
            return tot
        before=regscore()
        g[r1][c1],g[r2][c2]=g[r2][c2],g[r1][c1]
        after=regscore()
        ns=s + (after-before)
        if ns <= s or random.random() < math.exp((s-ns)/T):
            s=ns
            if s < bests:
                bests=s
                best=[row[:] for row in g]
                # print("best",bests,it)
                if bests==0:
                    return best,bests
        else:
            g[r1][c1],g[r2][c2]=g[r2][c2],g[r1][c1]
        T*=0.99997
        if T<0.001: T=0.001
    return best,bests

for diag in [False, True]:
    best,b=optimize(diag=diag, max_iter=100000)
    print("diag",diag,"best",b)
    if b==0:
        for row in best: print(row)
        print()

The resulting table:

1	2	3	4	5	6	7	8	9
Spades	Flowers	Mixed	Squares	Mixed	Dark Green	Mixed	Spades	Dark Green
Plaid	Dark Green	Light Green	Flowers	Plaid	Spades	Squares	Plaid	Flowers
Squares	Spades	Squares	Dark Green	Squares	Flowers	Dark Green	Mixed	Spades
Flowers	Plaid	Mixed	Spades	Mixed	Spades	Plaid	Squares	Plaid
Mixed	Dark Green	Flowers	Plaid	Flowers	Dark Green	Flowers	Spades	Flowers
Squares	Spades	Squares	Dark Green	Spades	Light Green	Plaid	Mixed	Plaid
Flowers	Dark Green	Plaid	Mixed	Plaid	Dark Green	Squares	Dark Green	Squares
Squares	Mixed	Spades	Squares	Flowers	Mixed	Flowers	Spades	Plaid

It took Chat GPT almost 45 seconds to arrive at a solution.

The Results

Once the physical squares were laid out, it was universally agreed that this was an ideal solution. The "why" it was an ideal solution remains a bit of a mystery. I do not know if this comes across in the image, but when looking at the physical quilt, your eye seems to first look for a pattern. The eye cannot find that pattern because there is none - that was the point. Interestingly, the brain accepts this as the whole of the quilt being the pattern and is happy to let you enjoy the chaos.

From here, Marna set to finalizing the squares and assembling the rows.

The result is not technically random - which was how we described it amongst our human selves. The pattern is really a structured approach to not having touching squares, which then seems to come across as pleasingly random. It would have taken us countless hours to arrive at the same "random" pattern. Leveraging a probability machine, er, LLM, made quick work of the task, and is a really fun example of how the digital and physical colliding in art can result in a very pleasing outcome.

Managing Tech: Cadence

2026-02-02T00:00:00Z

This is part of a series:

Managing Tech: People
Managing Tech: Heroes
Managing Tech: Professionals
Managing Tech: Time
Managing Tech: Cadence (you are here)
Managing Tech: 1:1

I have mentioned before that a manager's currency is meetings. This is markedly different from the individual contributor, whose currency is focus time. As a manager at Amazon, it was not uncommon for me to sit down at my desk on Monday morning and find that I already had 20 hours of meetings scheduled for the week. How could that possibly be the case?

In this post, I will walk through the meetings that should be on a manager's calendar, along with recommended timing and cadence. I will also discuss - at a high level - the purpose of each meeting and why it matters. Future posts will dive deeper into agendas and specific considerations for each meeting type.

Direct Report 1:1

Weekly, 30 minutes

You should have dedicated time with each of your direct reports every week. This is especially important for remote teams, but it applies just as strongly when you are co-located. This is their time to speak - to tell you how things are really going. While there should be dialogue, the primary flow of information should be from them to you. Communication flowing downward can happen in other meetings.

To that end, if an employee wants to cancel their 1:1 for the week, that is their prerogative. You, however, should respect the scheduled time and avoid canceling or rescheduling unless it is absolutely necessary. Canceling sends the message that your direct report is less important than other work - when, in reality, they are the reason your role exists. Rescheduling risks disrupting the focus time they have carefully arranged for their own productivity.

If you must reschedule, ask whether it works for them and what time they would prefer. Do not assume you understand their calendar well enough to make that decision unilaterally.

Remember that employees are people. Do you enjoy having your schedule changed without warning? If your mechanic needs to reschedule your car service, do you want them to simply pick a new time for you?

Preparation matters. You should never show up to a 1:1 without an agenda. By the time the meeting begins, you should already have a clear view of the employee's status. When did they last take time off? What goals have they stated? What follow-ups are pending?

I personally schedule 30-minute 1:1s, but I block 30 minutes on either side of each meeting. The time before allows me to prepare; the time after gives me space to capture notes and address action items. This ensures I am fully present - and it also allows the meeting to run long if needed.

Direct Reports Team Meeting

Weekly, 30–60 minutes

The team meeting is your opportunity to set and reinforce direction. This is where pass-down information belongs. This is manager talk time. Your goal is to ensure everyone is aligned - focused on the same point on the horizon - and that objectives are being communicated clearly.

You should also leave room for questions.

Remember that not everyone feels comfortable speaking up in a group setting. Avoid putting anyone on the spot. If you would like someone to share work or insights with the team, ask them privately during a 1:1. They may prefer to contribute via a written document, an email, or collaboration in team chat.

As someone inclined toward Socratic questioning, I have learned that questions meant to probe deeper meaning can sometimes be misinterpreted as "stupid." No question is stupid. Every question is valid. Psychological safety is essential - without it, valuable insights will remain unspoken.

Be careful with spillover from 1:1s. Personal information shared privately is not for team discussion unless explicitly acknowledged and agreed upon.

Office Hours

Weekly, 60 minutes

When can employees reach you for clarification outside of structured meetings? I do not consider office hours mandatory unless you are managing through change. During periods of uncertainty, people often have questions after talking with peers, family, or simply reflecting during their commute.

Office hours create space for those questions.

In modern environments with persistent chat tools, office hours may be less necessary. Use your judgment. Your role exists because your direct reports exist. Be available to them.

Manager 1:1

Weekly, 30–60 minutes

Just as you meet with your direct reports weekly, you should meet with your manager weekly as well. The same principles apply - you are one of their direct reports. This is your time to gain clarity on expectations, performance, and priorities.

Thirty minutes is often sufficient, though some managers also use this time for pass-down communication, which may require a full hour.

Manager Team Meeting

Weekly, 60 minutes

This is the equivalent of your team meeting, but for your manager's direct reports. This is manager time - time to think about team needs and alignment with broader organizational goals. These meetings should be driven by your manager and primarily focused on pass-down information from higher-level discussions.

Peer Manager Meeting

Weekly, rotating, 30 minutes

I recommend meeting regularly with peer managers. I rotate through peers - one per week. With six peers, that is one meeting every six weeks with each.

These meetings help you grow and help others grow. Approach them with humility. You will learn about processes that work well elsewhere - and sometimes you will be the one offering guidance.

They are also a chance to build alliances. If you and your peers notice a broader issue or missed objective, this is the place to identify it and plan how to surface it constructively. This is not a gossip session. Complaining solves nothing; plotting a path forward does.

Partner Team Meetings

Weekly, 30–60 minutes

Partners are managers of teams your direct reports collaborate with - Product Managers, program leads, or even VPs. Whenever possible, attend these meetings. Your direct reports should also attend when their work is directly involved.

When a direct report is doing the hands-on work, your role is to support them - especially when priorities conflict or clarification is needed. You never want "because my manager said so" to be the explanation. Your presence allows you to explain trade-offs and course-correct in real time.

These meetings may surface important signals - declining revenue, shifting priorities, or organizational changes. Being early to these signals allows you to plan and communicate proactively with your manager.

Direct Reports Fun Meeting

Monthly, 60 minutes

People connect over shared interests. This meeting exists to foster personal relationships. While you may lead it initially, long-term ownership should shift to the team - perhaps a senior contributor or a natural facilitator.

Topics should vary widely: books, movies, hobbies, cooking. I have had team members give live cooking demos from their kitchens. These moments matter.

Your employees will talk without you present. That is healthy. Encourage it.

Attendance should be encouraged but never required. No one should feel guilty for skipping due to deadlines. Participation should also be optional - lurking is fine. The goal is freeform connection, not forced engagement.

Direct Report Performance Meeting

Quarterly, 60 minutes

This is an extended 1:1 focused on performance. Annual reviews should never be the first time feedback is shared. Quarterly cadence allows for course correction.

I like to work with three development goals per employee: short-, medium-, and long-term. This creates continuity and momentum.

These meetings must be honest and clear. You can see performance patterns across the team and organization - use that insight to collaborate on closing gaps. You are not responsible for achieving their goals, but you are responsible for helping chart the path.

This is also the right time to discuss potential moves into management and to gather materials for promotion narratives.

Feedback should flow both ways. Ask directly: "How am I doing as your manager?" and "What do you need from me to be successful?" If you have missed the mark, own it and improve.

Manager Performance Meeting

Quarterly, 60 minutes

This mirrors the performance discussion you have with your team, but with your manager. It is also an opportunity to validate or contextualize feedback you are hearing from your team and to identify concrete actions for improvement.

Partner Owner Meeting

Quarterly, 30 minutes

This is an executive-level 1:1 with business owners your team supports. Come prepared with accomplishments, current work, and future plans.

Use this time to understand the business deeply. Partners enjoy explaining their products and strategy - and that knowledge makes you a better advocate for alignment.

Always ask: "How are we doing?" If there are concerns, this is the moment to surface them.

Skip-Level Manager Meeting

Quarterly, 30 minutes

Encourage skip-level meetings - both for your employees and for yourself. These conversations remove narrative bias and provide fresh perspective. They help individuals understand how objectives connect across the organization and why certain decisions are being made.

In-Person Direct Report Meeting

Quarterly, all day

Applies mostly to remote managers.

Remote management requires intentionality. If budget allows, visit each direct report quarterly. Meet for coffee or lunch. Connect as people.

For co-located teams, consider a quarterly team lunch.

Annual Direct Report Performance Meeting

Annually, 60 minutes

If you are holding quarterly performance meetings, nothing in the annual review should come as a surprise. The structure may be more formal due to corporate requirements, but the substance should already be familiar.

Closing Thoughts

Take notes - lots of them. When no process is defined, I use Obsidian because Markdown is searchable and reusable (even as input to AI systems). I follow up each meeting with written notes.

When corporate tools exist, use them. Shared documents - with agendas prepared in advance - keep everyone aligned and eliminate ambiguity.

This list may feel exhaustive. It may be too much - or not enough - depending on your culture. But the core truth remains: managers spend time in meetings. Done well, those meetings build cohesion, alignment, and serendipity.

Did I miss a meeting? Drop me a note via the contact form below.

Managing Tech: Time

2026-01-26T00:00:00Z

This is part of a series:

Managing Tech: People
Managing Tech: Heroes
Managing Tech: Professionals
Managing Tech: Time (you are here)
Managing Tech: Cadence
Managing Tech: 1:1

If there is one skill I most commonly see underrepresented—among both individual contributors and managers alike - it is time management. As an individual contributor, weak time management makes it difficult to scale across the responsibilities that your business requires of you. As a manager, poor time management means you will represent neither your employer nor your employees particularly well.

In this post, I will review a range of time management approaches along a spectrum. You can compare these options, identify which best reflects your current approach, and explore alternatives. This post is intended for both individual contributors and managers.

Organization

The "why" of time management is straightforward: the more information you try to keep in your head, the less successful you will be at any one thing. The most basic approach to time management, then, is simply to get commitments out of your head.

This might be as simple as a paper calendar where you write down a task for a given day. If you prefer a digital workflow (as I do), you can use a calendar application and create an appointment for the day you intend to work on a task.

If you are going the digital route, I generally recommend placing the task at the time you usually start work or arrive at the office. That way, you are confronted with it immediately and can plan accordingly.

If you have multiple tasks scheduled for the same day, you can arrange them in an order that works for the project. This is basic prioritization, which I will return to later in the post.

Time Blocking

Once you are consistently putting tasks on your calendar, the next step is to account for how long those tasks will actually take - blocking off sections of time accordingly. Early on, you will almost certainly underestimate how long tasks take. Over time, you will develop better estimation skills.

A common misstep is forgetting to block time for tasks people take for granted: checking email, reviewing plans, or even eating lunch. I generally block the first 30 minutes of each day for email and planning.

It is easy to become overly precise and try to block time down to the minute. Instead, I suggest choosing a minimum block - 15 or 30 minutes - and sticking with it. Even if a task only takes 10 minutes, you might still allocate a 30-minute block. This gives you time to context switch and provides some buffer for unexpected changes.

Time blocking is useful not only for planning, but also for tracking past work. This can be invaluable during performance reviews when you need to recall what you’ve accomplished over the past year.

Eventually, you will find yourself with a fully blocked day - and then a new meeting request arrives. What now? This is where prioritization becomes essential.

Prioritization

...or learning to say “no.”

When a meeting request comes in for a day that’s already fully blocked, you need to decide what action to take. Which task takes priority?

My preferred approach comes from the Getting Things Done (GTD) system, which I’ve written about in another post. I will summarize it here for completeness:

Do It: If you can complete the task now, do it.
Defer It: You cannot do the task right now, so schedule time to do it later. Delegate It: If someone else can move the task forward, delegate it - and block time to follow up.
Drop It: Some tasks do not actually need to be done. These are often informational and can be offloaded to another system (for example, a notes or knowledge base tool).

Learning to say "no" is a critical part of time management. Having a clear framework for prioritization makes this easier—and less personal.

A Word About Context Switching

For the individual contributor, meetings are often a distraction from deep work. Keeping email and corporate chat open throughout the day introduces constant interruptions. This is why I prefer to block time specifically for these systems and keep them closed otherwise. Context switching is expensive, cognitively speaking.

For the manager, meetings are your currency. Still, if you feel the urge to email or message a direct report, pause for a moment and consider the impact of that interruption. Is this truly the best time? Is it urgent?

I try to set clear expectations with my direct reports around response times. My general rule of thumb is that they can expect a response from me within 24 hours - and I expect the same from them. I make it explicit that I do not expect anyone to be "on" all the time.

As a manager, you also need to be mindful of how you communicate. A message with the subject line "Can we talk?" can trigger unnecessary anxiety. It can sound like a termination conversation when all you wanted to ask about next week’s vacation plans. Whenever possible, be explicit about your intent and provide guidance such as "not urgent" or "when you have time."

Likewise, talk with your team about preferred communication channels. Some people favor email; others prefer chat. Knowing how your direct reports prefer to communicate reduces the chance that important messages get lost - or ignored.

A Word About Systems

There are as many time management systems as there are stars in the night sky. I have not counted, but you get the idea. Over my 25 years in technology, I have studied and used many different systems. Below are a few that have stood out to me.

Patterns vs. Systems

The key is to avoid treating any single system as the final answer. Time management is a skill. A system - understood as an explanation of an approach - can help you develop that skill. The real value lies in understanding why the system is structured the way it is.

When a system is treated as the solution itself, it can box you into a rigid way of thinking and limit growth. Look for the patterns underneath.

Benjamin Franklin

Benjamin Franklin used a daily schedule with a column of numbers down the center of the page: 5 through 12, then 1 through 12, and finally 1 through 4. This represented each hour of the day. On either side of the numbers, he recorded what he planned to do and what he actually did.

Franklin started his day at 5 a.m. and went to bed at a consistent time, allowing for seven hours of sleep.

That was his system. Does that mean you should start your day at 5 a.m.? Or sleep exactly seven hours? If you’re systematizing blindly, you might say yes. But the real lesson is the pattern: he started and ended his day consistently.

There are additional lessons in Franklin’s approach that are beyond the scope of this post, but well worth exploring.

Bullet Journal

For a long time, I preferred paper to digital. There was something satisfying about opening a notebook, uncapping a quality pen, and putting ink on the page. I still have notebooks from my time as a sales engineer (2000–2007), and I occasionally enjoy flipping through them to see what I was doing on this day years ago.

When I wanted more structure, I turned to the Bullet Journal system.

Getting Things Done

I have already referenced Getting Things Done. It is the system that resonated most strongly with me and the one that informs most of my current practices.

Franklin Covey

The original time management powerhouse, Franklin Covey once had physical stores in shopping malls where you could buy planners and stationery preconfigured for their system.

The key takeaway for me was simple: list the tasks you need to accomplish for the day. Cross off what you complete. Carry unfinished tasks forward to the next day.

What About Agile?

Agile approaches such as Scrum and Kanban are vast enough to warrant certifications. They are powerful tools, but in my experience, they are often overkill when mentoring or developing basic time management skills.

All you really need is a notebook or the calendar application that comes with your operating system. Anything more can distract from the core objective: building good habits. The best time management system is the one that works for you - whether that is a well-known framework or a custom blend of techniques.

I have had direct reports successfully use Agile systems for personal time management. That is fine if it works for them. However, it can become a blocker when everyone - including the company - is running a different interpretation of the same system.

Closing Thoughts

Time management is not something you "set up" once and then forget. It is a skill you practice, refine, and occasionally relearn as your role, responsibilities, and life change.

The mistake I see most often is treating a system as the solution. Systems are scaffolding. They help you learn the patterns - externalizing commitments, estimating time realistically, prioritizing intentionally, and protecting focus. Once you internalize those patterns, the specific tools matter far less.

For individual contributors, good time management creates space for deep work, learning, and sustained delivery. It reduces stress by making trade-offs explicit rather than implicit.

For managers, time management is leverage. How you manage your own time directly shapes how your team experiences work. Poor time management shows up as unnecessary interruptions, unclear priorities, and reactive leadership. Strong time management builds trust, predictability, and psychological safety.

You do not need a perfect system. You need an honest one - one that reflects how you actually work, not how you wish you worked. Start simple. Observe what breaks. Adjust. Repeat.

The goal is not to fill every minute of your day. The goal is to spend your time intentionally, on the work that actually matters.

Managing Tech: Professionals

2026-01-16T00:00:00Z

This is part of a series:

Managing Tech: People
Managing Tech: Heroes
Managing Tech: Professionals (you are here)
Managing Tech: Time
Managing Tech: Cadence
Managing Tech: 1:1

In my post, Managing Tech: People, I mentioned that the social contract between employee and employer has changed over the past several decades. At IBM in 2016 (just one decade ago), it was common to encounter people who had been with the company for twenty years or more. I myself spent almost fifteen years at Adobe (2000–2013).

By 2026, it is far more common to move between employers every few years. The reasons for this are many. The question then becomes: if the old contract is no longer relevant, what is the new contract?

Professionals

When I start working with a new direct report, I generally tell them something along the following lines:

You are an adult. You are a professional. I expect adult, professional behavior from you. You can work whatever hours you want, in whatever manner you want, within reason. You know best how you get work done. Do that. I trust you to deliver.

This is the contract I am proposing: you are a professional.

The Oxford Dictionary defines "professional" as "doing something as a paid job rather than as a hobby." That definition is a baseline. What matters more to me is the implied trust, accountability, and autonomy that come with it.

There are clarifications that surface along the way, of course. For example, attending meetings during normal business hours is expected. To me, that still falls under the umbrella of professional behavior.

Manage Your Business

Once this message is clear, I push the boundaries a little further with an explanation along the following lines:

Your job is your Business (capital “B”), and you are responsible for it. We all love to focus on product, but sometimes we are called into other business functions. Some days you may be in sales (communicating vertically about your performance). Some days it is marketing (communicating horizontally to ensure people know what you can do). If you don’t know how to do some of these, let me know, and I will mentor you through those skills.

For an employee, I generally think of their business functions as (in no particular order):

Product: Deliverables
Sales: Vertical communication (share your awesome)
Marketing: Horizontal communication (find other ways to contribute)
Finance: Expenses; ordering gear or equipment
Human Resources: Annual training and continuing education
Customer Success: Meetings (stakeholders, managers, etc.)
IT: Automating workflows and reporting
Leadership: Time management and mentoring

You cannot come in and just write code. To be successful, you must think about your business holistically. Touching all of these functions ensures that your business - and your career - runs smoothly.

For The Manager

This contract is not just for the direct report - it applies equally to the manager. You must hold yourself to the same standard. Failing to do so erodes trust, and once trust is gone, the contract no longer works.

I like to take this one step further:

Do not ask a direct report to do something that you have not done in the past, or are not willing to do in the present.

In tech, this idea can feel counterintuitive. Innovation never stops, and you may ask someone to deliver a feature you have never personally built. But this principle is not about that specific feature - it is about the nature of the work. You understand what delivery entails: the extra hours when needed, the on-call rotation, the pressure of deadlines, and the responsibility that comes with ownership. That shared understanding matters.

If an employee has a family emergency, are you willing to step in, roll up your sleeves, and write some code? If someone is struggling with part of a feature, are you willing to schedule time, open the code, and work through it together - even if your role is simply to be a second set of eyes or a sounding board?

If you are asking a direct report to grow, stretch, or take on responsibility, you must be willing to do that work alongside them. That means using your experience to help define manageable goals, checking in on progress, and coaching - not delegating and disappearing.

A new contract with employees does not absolve you from the work. It raises the bar for how you show up as a manager.

The Professional Contract

This is often a new perspective for employees, but one that is both empowering and rooted in trust. I try to regularly schedule time to coach people through these ideas. By laying out the contract in terms of familiar business functions, we establish a shared framework - and a shared understanding - of what it truly means to be a professional in today’s world.

Managing Tech: Heroes

2026-01-14T00:00:00Z

This is part of a series:

Managing Tech: People
Managing Tech: Heroes (you are here)
Managing Tech: Professionals
Managing Tech: Time
Managing Tech: Cadence
Managing Tech: 1:1

Have you ever heard the term "elevator pitch"? You usually hear it in the context of pitching an idea to senior management or to investors. The idea is that the pitch for your idea or business should take no longer than an elevator ride - because that is all the time you might get.

One morning, I happened to be sharing an elevator ride with a vice president at the company. It was just the two of us. He asked, "What is your team up to these days?" Feeling witty, I responded, "Making heroes." A few days later, I heard the VP use that same phrase on a conference call - in a completely different way than I had intended.

From that point on, I always made sure to finish the phrase.

Heroes

In my last post, Managing Tech: People, I mentioned that people bring their own desires and goals to work. As a manager, you should make it a priority to understand what those desires and goals are for your employees - to make people heroes for what it is that they want to achieve.

This is awkward at first. You will get the standard "Where do you want to be in five years?" type of dialogue. The kind of dialogue that carries hints of fear and reservation. A dialogue that is truthful, but not honest. That is a fine place to start, but you want to go deeper.

If you are treating your employees like people - and you are listening closely (not just hearing) - you will begin to pick up on more honest feedback over time. As trust builds, that dialogue can become particularly transparent. More on that in a moment.

Sometimes the feedback is easy to address. Something along the lines of: "I want to learn a new skill." Great! Now you have a place to start - from which you can work backward. If the objective is X, what are the steps needed to get there? Think those through and discuss them with your employee. Work together to design and define goals. Check in on progress. Check them off. And celebrate those completions together.

I generally like to have one to three goals like this set up for each employee at all times. Some may be achievable in the short term, while others may take longer. Pin goals to a year or less to best align with performance reviews.

Radical Transparency

Sometimes the feedback is surprising. If you have truly built trust - or if the employee is just that bold - you might hear something like: "I do not want to work in this department." I have heard, "I don’t want to work for this company." I have even heard, "I don’t want to work on your team."

If you are making heroes, perhaps these are antiheroes - heroes all the same, just unconventional.

This is actually a breakthrough win. If you reach this level of dialogue, you should feel good about what you have accomplished as a manager. If an employee does not want to be part of the team, department, or company, you want to know. You do not want that sentiment lingering in the background, quietly poisoning the team, the project, or the culture.

You still want to make them heroes for what they want to achieve.

The phrase "I do not want to work for this company" is really shorthand for "I want to work for a different company." My response to that sentiment often surprises people. I will follow it with: "Where do you want to work?" and "What role would you like to have there?" Make that a goal and work backward to plan the steps to get there. I may even have contacts at that company I can introduce.

"I do not want to work in this department" strikes me the same way, but it is often easier to address. You already know how to network within your own company - and that is usually far easier than doing so externally. In these situations, I have reached out to managers in other departments and set up mentoring conversations for the employee.

This helps both the employee and me understand what steps need to be taken. Maybe there are skills to develop. Certifications to earn. Or maybe everything is a perfect fit and we are simply waiting for a position to open. In some cases, I have even coordinated work between the employee and the manager in their target department. The manager gets extra help, the employee sees a real path forward, and I alleviate potential toxicity on my own team.

Still People

Helping employees define goals that will make them heroes - and collaborating with them to get there - can start to feel mechanical if you are not careful. You have to remember that your employees are still people.

I once had an employee tell me they wanted to swim to Alcatraz (Sharkfest). What an interesting personal goal. I did not make this a corporate objective, but I did follow up on their progress from time to time. When they fell behind in training, I encouraged them to stay the course. When they hit milestones, I congratulated them. When they signed up and were ready for the swim, I booked a flight to San Francisco to cheer them on.

Careful of the "friend zone" I showed up, watched the event, took a picture with the employee when they finished, and then went on my way - letting them celebrate with their support team and friends who had helped them along the journey.

Stay on Target

You might think that helping an employee leave the company is misaligned with company goals - but it often is not. In the technology sector, it is commonly estimated that an employee departure costs a company around $100k. More importantly, disengaged employees cost far more while they stay.

When you come alongside an employee - when you listen, build trust, and help them become a hero for what they want to achieve - you reduce that hidden cost. Sometimes the result is growth within the team. Sometimes it is a move to another department. And sometimes it is a well-supported exit.

That is not a failure of management. It is management.

Managing tech is not about extracting maximum output from people. It is about creating the conditions where people can do meaningful work, grow honestly, and move forward with clarity - even when that path eventually leads away from you.

If you make people heroes for what it is that they want to achieve, the business outcomes tend to take care of themselves.

Managing Tech: People

2026-01-12T00:00:00Z

This is part of a series:

Managing Tech: People (you are here)
Managing Tech: Heroes
Managing Tech: Professionals
Managing Tech: Time
Managing Tech: Cadence
Managing Tech: 1:1

You are good at your job. You come into work, consistently deliver results, and keep learning more about the business and your craft. Eventually, your abilities are noticed and you are promoted to manager. Congratulations!

There is just one problem: the skills that made you successful as an individual contributor (IC) no longer serve you as a manager. You struggle for a while, then eventually decide to return to your previous role.

There is no shame in that. I have seen this happen time and again.

The other day, I was talking to a friend who had gone through this exact process. After years of being comfortably back in his IC role, he is once again being formally nudged toward management. Knowing that I have managed technical teams for nearly 20 years, he asked me for some advice.

I took a deep breath, sat with the question for a moment, and suggested...

People

When it comes to managing people - especially in tech - my first thought is simple: remember that your employees are people.

This sounds obvious, but tech cultures are often tuned to extract as much value from employees as possible. If you are not careful, those employees can start to look like cogs. Cogs are replaceable when they stop working. People are not.

Every employee brings a full life with them to work every day: desires, goals, problems, stresses, emotions - everything from the journey that led them to this role. When you interact with your employees, interact with them as people.

When you have a 1:1, ask, "How are you?" Mean it. Listen - not just hear - the response. Ask follow-up questions. Try to understand their perspective in that moment. What is motivating them? What is weighing on them? Is there anything you need to do?

Sometimes the answer is no. Most of the time, it is. But if you listen closely enough, you will occasionally find moments where you can change the trajectory of an employee’s work—and sometimes their experience at the company.

No Free Pass

You might be thinking this is ridiculous.

You pay these people to show up and do a job. What happens outside of work is n0t your concern. Just deliver. Deal with your baggage on your own time.

The problem with this mindset is that humans are social animals. Even introverts - even the shy - need social interaction (just the right kind). By ignoring who your employees are as people, you are ignoring the very interactions that shape who they are at work.

The social contract between employee and employer has changed dramatically over the past several decades - especially in tech.

If there are 24 hours in a day and an employee works an eight-hour shift, that leaves 16 other hours influencing how they show up. Ignoring that reality means ignoring roughly 66% of what makes your employee your employee.

Would you ignore 66% of your business?
Would you leave 66% of your revenue on the table?

This is not a free pass. It is compassion. It is empathy for another human being. It is not a "get out of jail free" card.

As a manager, you still need results. Deadlines still exist. The company is looking to you to deliver. Treating employees as people does not change that - it gives you a better way to lead through it.

If an employee wakes up with a flat tire and arrives late, the key question is not "Why are you late?" It is "Will this impact deliverables?"

If it will, how can you reallocate resources to keep things on track? Maybe another employee has been looking for a chance to stretch. Maybe someone else wants exposure to a different project. You can only make those decisions if you understand your people.

Now think about the employee with the flat tire. It is stressful. It is frustrating. You would probably appreciate a little flexibility to fix the problem and move on. Offer that time. Let them resolve the issue quickly so they can return focused and productive.

That is what you actually want: problems resolved in a way that still allows the team to deliver.

A welcome side effect of this approach is trust. Trust leads to loyalty - to you, to the team, and sometimes to the company. And the next time someone else needs help, that employee is far more likely to pay it forward.

A Word of Caution

Treating employees as people is critical - but remember that you are still the manager.

You will write performance reviews. You will adjust compensation. You may have to let someone go. There may be reorganizations that move people across teams. If you get too close, these moments can create real legal and organizational risk.

You are not their friend. You are their manager.

Empathy and humanity will help you lead through change, but crossing fully into the "friend zone" should be avoided. You do not need to enforce hierarchy - but you do need to maintain a healthy, professional distance.

Web Component Template

2026-01-09T00:00:00Z

Web Components get a bad rap. They are often described as too long, too verbose, or burdened with boilerplate. I recently had ChatGPT migrate the “label” component from the previous post to React. The result was less readable and nearly twice as long. Between recurring React security issues and the latest "Tailwind is dead" discourse, the ecosystem feels noisier than ever.

While there are a number of different ways to leverage the various standards that make up Web Components, I like a Shadow DOM implementation that leans on composability wherever possible - especially via slots, parts, and predictable APIs. My component template is pretty dialed in. I have built hundreds of components this way, and it is the approach I keep coming back to.

I have implemented applications with Light DOM as well, and never quite developed a workflow I liked. Perhaps as somebody that has built applications with technologies like Java Swing and Visual Basic, the Shadow DOM approach just resonates more with me.

Top and Bottom

The opening line of the template extends the HTMLElement class. This is standard for Web Components. For the name of the subclass, I like to use the prefix I intend to use for the component, followed by a name that describes the component. For example, a button component with the kh- prefix would become KhButton. In this post, we will use KhTemplate as a generic example.

export default class KhTemplate extends HTMLElement {
  ...
}

window.customElements.define( 'kh-template', KhTemplate );

The last line of the template wires up the subclass to the element name. The prefix must be present. The most common prefix is generally two or three letters, but I have seen complete words, and even multiple words used as a prefix (for example solar-system-sun, solar-system-earth). My guidance would be to use whatever makes resulting code most readable. Consistency is key.

Constructor

The first part of the constructor defines the styles and markup that make up the component. I generally include a :host CSS block that contains at least box-sizing: border-box, display: inline-block, and position: relative.

The box-sizing model helps make the layout more predictable. The display can be whatever you need, I prefer to specify it for consistency and maintainability. The relative position comes in handy when you need to absolutely position something inside the component like a tooltip or ::after content.

constructor() {
  super();

  const template = document.createElement( 'template' );
  template.innerHTML = /* template */ `
    <style>
      :host {
        box-sizing: border-box;
        display: inline-block;
        position: relative;
      }
    </style>
    <p part="label">Hello world!</p>
  `;

  ...
}

I also like to include the part attribute whenever I think the element may need to be styled by the developer. I find that if I am reaching for id or class to be able to reference the element, then I should probably just use a part name. This makes the part stylable, and easy to reference with querySelector().

The second part of the constructor is declaring everything the component needs. I start with properties, and have specific default values I like to use. I also use the underscore (_) character to denote that these are "private".

// Properties
this._anArray = [];
this._aDate = null;
this._anObject = null;
    
// Events
this.onComponentClick = this.onComponentClick.bind( this );

// Root
this.attachShadow( {mode: 'open'} );
this.shadowRoot.appendChild( template.content.cloneNode( true ) );

// Elements
this.$label = this.shadowRoot.querySelector( 'p[part=label]' );

Most components handle some form of events internally. Here is where we declare those events. I use bind() so that they are also easily removed. Events get wired up later in the connectedCallback() method.

Next, we stamp out the template by attaching it to the component’s shadowRoot.

Finally, any element references you will need during the life of the component. I like to use $ to indicate that this property refers to an element. This allows me to have a property this._label align with an element this.$label to make things more readable.

Event Handlers

After the constructor, I will define any of the events I referenced inside the constructor.

onComponentClick( evt ) {
  this.dispatchEvent( new CustomEvent( 'kh-event', {
    bubbles: true,
    cancelable: false,
    composed: true,
    detail: {
      'abc': 123
    }
  } ) );
}

I do not generally like to rely on bubbling - either of native events or events that my components dispatch. If there is a button element inside my component, I will attach a click handler inside the component and in turn have the component dispatch something more relevant - even if it is just an kh-click. Whenever I use my components then, I always listen for the component specific event.

I like to think that this makes the event handling easier to follow, and that it avoids any collision with other components I may be using (especially in a composable manner). In practice, I have never encountered any problems getting the right event from the right component.

Rendering Content

The _render() method is where I update the elements within the component based on changes to attributes or properties. If the changes come from attribute changes, I will reference those access methods directly. If the changes are coming from property changes, then I will reference the internal property such as this._value directly.

Never set an attribute or property of the component itself from inside the _render() method. This will result in an infinite loop.

// When attributes change
_render() {
  this.$label.textContent = this.aString === null ? '' : this.aString;
}

In the case of something like a calendar component, where there are ~50 elements inside the component, this method definition can get pretty lengthy. Think of this as working with a scalpel, not a virtual DOM. You can set the textContent of the this.$label instance repeatedly without a performance impact.

The Upgrade

Depending on how your component is used, property values may be assigned before the component has had a chance to initialize. If this happens, any property values that were assigned will become undefined. To get around this, as part of the initialization, I leverage a method named _upgrade(). We will see this more in a moment.

// Promote properties
// Values may be set before module load
_upgrade( property ) {
  if( this.hasOwnProperty( property ) ) {
    const value = this[property];
    delete this[property];
    this[property] = value;
  }
}

The _upgrade() method checks for the existence of a property value. If it exists, that property is referenced to a local value. The property value itself is then deleted, and then immediately set with the local value. This ensures that any properties assigned before upgrade are properly re-applied once the component is fully initialized.

Connect and Disconnect

When a component is attached to the DOM, it calls the connectedCallback() method. This is where you can wire up your events, and perform an initial render. When the component is removed from the DOM, it calls the disconnectedCallback() method. This is where you want to remove any event handlers.

// Setup
connectedCallback() {
  this.$label.addEventListener( 'click', this.onComponentClick );
    
  this._upgrade( 'anArray' );      
  this._upgrade( 'aBoolean' );
  this._upgrade( 'aDate' );    
  this._upgrade( 'aFloat' );      
  this._upgrade( 'anInteger' );            
  this._upgrade( 'anObject' );    
  this._upgrade( 'aString' ); 
  
  this._render();
}

// Set down
disconnectedCallback() {
  this.$label.removeEventListener( 'click', this.onComponentClick );
}

Here is where the _upgrade() method shows up. You should apply the upgrade to all attribute and property values that are exposed externally. Now that we are sure the state of the component is what the developer expected, we can call _render() to place all the values in the component DOM.

Attributes

We are almost done implementing our web component. We have attributes and properties remaining.

The observedAttributes() method is part of the specification that tells the component what attributes might change at runtime. This means that if you set a data-id attribute on the element at runtime, and the data-id attribute is not declared in observedAttributes(), then no updates will happen to the component - the attribute is not registered - and that may be what is desired.

A "label" component on the other hand will likely have a text attribute. We expect the internal DOM of the component to be updated when that attribute is added, changed, or removed. For this change to happen, we need to tell the component about the attribute.

We do not need to list properties here - they are handled directly via their setters.

// Watched attributes
static get observedAttributes() {
  return [
    'a-boolean',
    'a-float',    
    'an-integer',    
    'a-string'
  ];
}

// Observed attribute has changed
// Update render
attributeChangedCallback( name, old, value ) {
  this._render();
}

When an attribute is changed, the _render() method is called to update the DOM. This may look different than some other component implementations you may have seen. This is because in this implementation, some property changes may change the DOM as well. Rather than have that code in multiple places, it gets centralized in the _render() method.

Properties

Technically attributes can only be strings. We will add some syntactic sugar in a moment to be able to handle basic types such as integers, floats, and booleans. There are times however when you really need to pass an object to the component. That is where properties come into play.

I have specific signatures I like to use for my properties. I will declare them in the constructor with a default value, and assign them there for any runtime changes.

// Properties
// Not reflected
// Array, Date, Object, null
get anArray() {
  return this._anArray.length === 0 ? null : this._anArray;
}

set anArray( value ) {
  this._anArray = value === null ? [] : [... value];
}

get aDate() {
  return this._aDate;
}

set aDate( value ) {
  this._aDate = value === null ? null : new Date( value.getTime() );
}

get anObject() {
  return this._anObject;
}

set anObject( value ) {
  this._anObject = value === null ? null : structuredClone( value );
}

Properties are defined using access methods. When working with them at runtime, they take on the same look at when working with attributes (label.text = 'Hello world.'). Regardless of properties or attributes, I force the default to null for consistency (with the exception of boolean attributes). I also assign by value, and return by reference by convention across all of my components. These conventions keep everything consistent.

In order to keep the consistency for attributes, and in order to add that syntactic sugar to handle specific data types, we also implement access methods for attributes.

// Attributes
// Reflected
// Boolean, Float, Integer, String, null
get aBoolean() {
  return this.hasAttribute( 'a-boolean' );
}

set aBoolean( value ) {
  if( value !== null ) {
    if( typeof value === 'boolean' ) {
      value = value.toString();
    }

    if( value === 'false' ) {
      this.removeAttribute( 'a-boolean' );
    } else {
      this.setAttribute( 'a-boolean', '' );
    }
  } else {
    this.removeAttribute( 'a-boolean' );
  }
}

get aFloat() {
  if( this.hasAttribute( 'a-float' ) ) {
    return parseFloat( this.getAttribute( 'a-float' ) );
  }

  return null;
}

set aFloat( value ) {
  if( value !== null ) {
    this.setAttribute( 'a-float', value );
  } else {
    this.removeAttribute( 'a-float' );
  }
}

get anInteger() {
  if( this.hasAttribute( 'an-integer' ) ) {
    return parseInt( this.getAttribute( 'an-integer' ) );
  }

  return null;
}

set anInteger( value ) {
  if( value !== null ) {
    this.setAttribute( 'an-integer', value );
  } else {
    this.removeAttribute( 'an-integer' );
  }
}

get aString() {
  if( this.hasAttribute( 'a-string' ) ) {
    return this.getAttribute( 'a-string' );
  }

  return null;
}

set aString( value ) {
  if( value !== null ) {
    this.setAttribute( 'a-string', value );
  } else {
    this.removeAttribute( 'a-string' );
  }
}

These attribute access methods handle the updates to the attributes themselves (a technique commonly called "attribute reflection"). When the attribute access methods are invoked, they will in turn trigger the attributeChangedCallback() method, which will in turn call the _render() function to update the internal DOM as necessary.

Note that the naming convention used in these code snippets is designed to indicate a specific data type. You will want to update/use these snippets to map to your specific API surface. For example, if you have text attribute, then you would implement the aString() access methods, but name the methods text().

Next Steps

I will place the entire template below for reference. You can also find it as a GitHub Gist. I have implemented hundreds of components using this approach, and deployed them in production applications such as Anno Awesome and Flavor Awesome. If you are looking for more examples, check out my Vanilla JS implementations of Amazon Cloudscape and IBM Carbon for more examples.

export default class KhTemplate extends HTMLElement {
  constructor() {
    super();

    const template = document.createElement( 'template' );
    template.innerHTML = /* template */ `
      <style>
        :host {
          box-sizing: border-box;
          display: inline-block;
          position: relative;
        }

        :host( [a-boolean] ) {
          display: none;
        }
        
        hoyt-component::part( inner ) {
          --component-stylet: var( --my-component-style, #123456 );
        }
      </style>
      <hoyt-component exportparts="inner: outer" part="also-outer"></hoyt-component>
    `;
    
    // Properties
    this._anArray = [];
    this._aDate = null;
    this._anObject = null;
    
    // Consider for mobile
    this._touch = ( 'ontouchstart' in document.documentElement ) ? 'touchstart' : 'click';

    // Events
    this.onComponentClick = this.onComponentClick.bind( this );

    // Root
    this.attachShadow( {mode: 'open'} );
    this.shadowRoot.appendChild( template.content.cloneNode( true ) );

    // Elements
    this.$component = this.shadowRoot.querySelector( 'element-name' );
  }
  
  onComponentClick( evt ) {
    this.dispatchEvent( new CustomEvent( 'kh-event', {
      bubbles: true,
      cancelable: false,
      composed: true,
      detail: {
        'abc': 123
      }
    } ) );
  }

   // When attributes change
  _render() {
    this.$component.aBoolean = this.aInteger === null ? false : true;
  }

  // Promote properties
  // Values may be set before module load
  _upgrade( property ) {
    if( this.hasOwnProperty( property ) ) {
      const value = this[property];
      delete this[property];
      this[property] = value;
    }
  }

  // Setup
  connectedCallback() {
    this.$component.addEventListener( 'click', this.onComponentClick );
      
    this._upgrade( 'anArray' );      
    this._upgrade( 'aBoolean' );
    this._upgrade( 'aDate' );    
    this._upgrade( 'aFloat' );      
    this._upgrade( 'anInteger' );            
    this._upgrade( 'anObject' );    
    this._upgrade( 'aString' ); 
    
    this._render();
  }
  
  // Set down
  diconnectedCallback() {
    this.$component.removeEventListener( 'click', this.onComponentClick );
  }

  // Watched attributes
  static get observedAttributes() {
    return [
      'a-boolean',
      'a-float',    
      'an-integer',    
      'a-string'
    ];
  }

  // Observed attribute has changed
  // Update render
  attributeChangedCallback( name, old, value ) {
    this._render();
  } 
  
  // Properties
  // Not reflected
  // Array, Date, Object, null
  get anArray() {
    return this._anArray.length === 0 ? null : this._anArray;
  }
  
  set anArray( value ) {
    this._anArray = value === null ? [] : [... value];
  }
  
  get aDate() {
    return this._aDate;
  }
  
  set aDate( value ) {
    this._aDate = value === null ? null : new Date( value.getTime() );
  }
  
  get anObject() {
    return this._anObject;
  }
  
  set anObject( value ) {
    this._anObject = value === null ? null : structuredClone( value );
  }    

  // Attributes
  // Reflected
  // Boolean, Float, Integer, String, null
  get aBoolean() {
    return this.hasAttribute( 'a-boolean' );
  }

  set aBoolean( value ) {
    if( value !== null ) {
      if( typeof value === 'boolean' ) {
        value = value.toString();
      }

      if( value === 'false' ) {
        this.removeAttribute( 'a-boolean' );
      } else {
        this.setAttribute( 'a-boolean', '' );
      }
    } else {
      this.removeAttribute( 'a-boolean' );
    }
  }
  
  get aFloat() {
    if( this.hasAttribute( 'a-float' ) ) {
      return parseFloat( this.getAttribute( 'a-float' ) );
    }

    return null;
  }

  set aFloat( value ) {
    if( value !== null ) {
      this.setAttribute( 'a-float', value );
    } else {
      this.removeAttribute( 'a-float' );
    }
  }
  
  get anInteger() {
    if( this.hasAttribute( 'an-integer' ) ) {
      return parseInt( this.getAttribute( 'an-integer' ) );
    }

    return null;
  }

  set anInteger( value ) {
    if( value !== null ) {
      this.setAttribute( 'an-integer', value );
    } else {
      this.removeAttribute( 'an-integer' );
    }
  }
  
  get aString() {
    if( this.hasAttribute( 'a-string' ) ) {
      return this.getAttribute( 'a-string' );
    }

    return null;
  }

  set aString( value ) {
    if( value !== null ) {
      this.setAttribute( 'a-string', value );
    } else {
      this.removeAttribute( 'a-string' );
    }
  }        
}

window.customElements.define( 'kh-template', KhTemplate );

The Unsung UI Control: Label

2026-01-06T00:00:00Z

Whenever I start designing a new UI, inevitably, one of the first components I create is a Label component. You might think that the Label is unnecessary because that is what the paragraph element (p) does. And you would be partly correct. But then you have likely seen an Input element or a Checkbox element, and those are HTML native types as well (input type="text", input type="checkbox"). Same with Button, TextArea, and others.

When you think about wrapper components like Input, at a minimum they are adding functionality. In many cases component wrappers around native HTML elements will also be enforcing styling to the design system itself. With that in mind, let us take a look at how I approach building a Label component.

The only design system I have seen do this implicitly is Amazon Cloudscape with it's Box component.

Foundations

I think Web Components have gotten a bad rap for being especially verbose and/or complex. This can certainly be true when you have data binding in frameworks such as Svelte, but you still need the basics in both - the CSS and the root element. From there it is a matter of extending the HTMLElement class, and attaching the template to the DOM of the element.

This is the Shadow DOM approach. The alternative Light DOM approach also needs the root element and the CSS, though they will appear in different places. This is not an article about which is better. Context is key. For this example however, I will be focused on the Shadow DOM approach.

export default class HoytLabel extends HTMLElement {
  constructor() {
    super();

    const template = document.createElement( 'template' );
    template.innerHTML = /* template */ `
      <style>
        :host {
          box-sizing: border-box;
          display: inline-block;
          position: relative;
        }

        p {
          color: var( --label-color, #161616 );
          font-family: 'Open Sans', sans-serif;
          font-size: var( --label-font-size, 16px );
          font-weight: var( --label-font-weight, 400 );
          letter-spacing: var( --label-letter-spacing, 0.10px );
          line-height: var( --label-line-height, 24px );
          margin: var( --label-margin, 0 );
          padding: var( --label-padding, 0 );
          width: var( --label-width, 100% );
        }
      </style>
      <p part="label">
        <slot></slot>
      </p>
    `;
    
    // Root
    this.attachShadow( {mode: 'open'} );
    this.shadowRoot.appendChild( template.content.cloneNode( true ) );
  }
}

window.customElements.define( 'kh-label', HoytLabel );

I have included CSS variables for the paragraph element. Each of these set a default value for their respective style property. This is my approach. You might alternatively be inclined to use CSS :root in your main CSS file, and define these variables there.

When I think of a Svelte component, as an example, the styles are included in the same *.svelte file. I like that the element and the styles are together, so I keep that approach in my components. I also like my styles to be closer to the component so that I do not have to go looking around to other files. I have also found that when using components, I want to nudge them slightly here or there. I like to do that nudging closer to the declaration to avoid inadvertant cascading.

Some design systems lock down the styles that can be used to force consistency across a large organization (again, see Amazon Cloudscape).

The component implementation here includes a slot element. Anything placed inside the component declaration will show up there - between the p tags. The component is used (at this point) as follows.

<kh-label>Hello world!</kh-label>

Adding Functionality

For almost every component I implement, I include a hidden attribute. The hidden attribute already exists in HTML, but when you are building custom elements, you need to decide how (or if) it should be implemented. When I use hidden, I want the element to be removed from the DOM. In CSS terms, that is the display: none property.

export default class HoytLabel extends HTMLElement {
  constructor() {
    super();

    const template = document.createElement( 'template' );
    template.innerHTML = /* template */ `
      <style>
        :host {
          box-sizing: border-box;
          display: inline-block;
          position: relative;
        }

        :host( [hidden] ) {
          display: none;
        }

        p {
          color: var( --label-color, #161616 );
          font-family: 'Open Sans', sans-serif;
          font-size: var( --label-font-size, 16px );
          font-weight: var( --label-font-weight, 400 );
          letter-spacing: var( --label-letter-spacing, 0.10px );
          line-height: var( --label-line-height, 24px );
          margin: var( --label-margin, 0 );
          padding: var( --label-padding, 0 );
        }
      </style>
      <p part="label">
        <slot></slot>
      </p>
    `;
    
    // Root
    this.attachShadow( {mode: 'open'} );
    this.shadowRoot.appendChild( template.content.cloneNode( true ) );
  }
}

window.customElements.define( 'kh-label', HoytLabel );

In the style block of the component, we use the :host() selector to apply styling when a hidden attribute is present in the component instance. We can then make the component hidden using:

<kh-label hidden>Hello world.</kh-label>

Easy enough. Another attribute I like to add is concealed which toggles the CSS visibility property for the times I do not want to remove the element from the DOM, but just make it invisible.

:host( [concealed] ) {
  visibility: hidden;
}

<kh-label concealed>Hello world.</kh-label>

Sometimes you want text to be truncated with an ellipsis (by default in this configuration text will wrap). For this, we can implement a truncate attribute, that gets applied to the contained paragraph element.

:host( [truncate] ) p {
  overflow: hidden;
  text-overflow: ellipsis;  
  white-space: nowrap;
}

<kh-label style="width: 150px;" truncate>Hello world, or some other really long greeting.</kh-label>

Nice! Now we are having some fun. Let us keep going.

While you can style the Label component using the CSS variables, some design systems may not want to leave the options that wide open. They still recognize that there will be different style choices in different contexts, but they do not want developers departing from the system (prescribed look and feel). A happy middle ground here is to supply attributes that style the element, but do so within a range of fixed possibilities.

Take the font color for example. Design systems will have already decided what the default color will be (usually slightly off-black). What if you want to use the Label component in an error situation? You will most likely want to change the font color to some variation of red. In a design system, that variation of red will already have been determined for you. In this fashion, any time an error is presented, across any of the applications using the design system, will show the same color of red. This means that rather than add a color attribute that takes any color value, that color reflects usage. It is that usage that is assigned to the color attribute - and by extension helps to describe the usage of the component instance in the code.

:host( [disabled] ) p, :host( [color=disabled] ) p {color: #656871;}
:host( [color=error] ) p {color: #db0000;}
:host( [color=info] ) p {color: #006ce0;}
:host( [color=success] ) p {color: #00802f;}
:host( [color=warning] ) p {color: #855900;}

<kh-label color="error">Hello world.</kh-label>

The same approach is often used for font sizing and font-weight.

:host( [size='body-xs'] ) p {font-size: 12px; line-height: 16px;}
:host( [size='body-sm'] ) p {font-size: 14px; line-height: 20px;}
:host( [size='heading-xs'] ) p {font-size: 16px; line-height: 20px;}
:host( [size='heading-sm'] ) p {font-size: 18px; line-height: 22px;}

:host( [weight=light] ) p {font-weight: 300;}
:host( [weight=bold] ) p {font-weight: 700;}

<kh-label color="error" size="body-xs" weight="bold">Hello world.</kh-label>

This is where having a Label component in your design system really starts to shine as compared to using a paragraph element. The API of the component can inform developers of the expected usage, while at the same time ensuring consistency. Think of the 200+ products offerred by Amazon Web Services. Each has it's own team of developers. Each has it's own UX/UI needs. Yet (like them or not) they all look the same.

Extending Functionality

Up to this point we have been adding attributes and applying corresponding styles all with CSS - no additional JavaScript code needed. With this approach, if you want an attribute to be updated dynamically, you would have to use the setAttribute() method.

const label = document.querySelector( 'kh-label' );
label.setAttribute( 'weight', 'bold' );

// Or to remove
label.removeAttribute( 'weight' );

If you directly set label.weight = 'bold', then no changes to the label will appear to take place. There is work being done - a property called weight is being set on the Label instance. Just like any JavaScript object, you can apply random properties all you want. They will not do anything, but you can apply them.

To get at the root cause of this behavior, we have to think a little more critically about what it is that we are trying to accomplish with the use of label.weight = 'bold'. What we really want to happen is for the attribute weight to be added to the component instance, and the value of bold to be assigned to that attribute. This will in turn trigger the CSS styles.

Note the distinction here between setting a property and setting an attribute.

When we want a Web Component property and attribute to have the same behavior, that is called reflection. To get basic reflection, we add access methods (get/set) to the component, and have those methods update the attributes accordingly.

export default class HoytLabel extends HTMLElement {
  constructor() {
    super();

    const template = document.createElement( 'template' );
    template.innerHTML = /* template */ `
      <style>
        :host {
          box-sizing: border-box;
          display: inline-block;
          position: relative;
        }

        :host( [concealed] ) {
          visibility: hidden;
        }

        :host( [hidden] ) {
          display: none;
        }

        :host( [truncate] ) p {
          overflow: hidden;
          text-overflow: ellipsis;          
          white-space: nowrap;
        }

        p {
          color: var( --label-color, #161616 );
          font-family: 'Open Sans', sans-serif;
          font-size: var( --label-font-size, 16px );
          font-weight: var( --label-font-weight, 400 );
          letter-spacing: var( --label-letter-spacing, 0.10px );
          line-height: var( --label-line-height, 24px );
          margin: var( --label-margin, 0 );
          padding: var( --label-padding, 0 );
        }

        :host( [disabled] ) p, :host( [color=disabled] ) p {color: #656871;}
        :host( [color=error] ) p {color: #db0000;}
        :host( [color=info] ) p {color: #006ce0;}
        :host( [color=success] ) p {color: #00802f;}
        :host( [color=warning] ) p {color: #855900;}
        
        :host( [size='body-xs'] ) p {font-size: 12px; line-height: 16px;}
        :host( [size='body-sm'] ) p {font-size: 14px; line-height: 20px;}
        :host( [size='heading-xs'] ) p {font-size: 16px; line-height: 20px;}
        :host( [size='heading-sm'] ) p {font-size: 18px; line-height: 22px;}

        :host( [weight=light] ) p {font-weight: 300;}
        :host( [weight=bold] ) p {font-weight: 600;}        
        :host( [weight=heavy] ) p {font-weight: 700;}        
      </style>
      <p part="label">
        <slot></slot>
      </p>
    `;
    
    // Root
    this.attachShadow( {mode: 'open'} );
    this.shadowRoot.appendChild( template.content.cloneNode( true ) );
  }

  get weight() {
    if( this.hasAttribute( 'weight' ) ) {
      return this.getAttribute( 'weight' );
    }

    return null;
  }

  set weight( value ) {
    if( value !== null ) {
      this.setAttribute( 'weight', value );
    } else {
      this.removeAttribute( 'weight' );
    }
  }  
}

window.customElements.define( 'kh-label', HoytLabel );

It is not as slick as data binding with a Svelte rune, but it also does not add much complexity. One set of access methods per reflected property. You can also add a bit of syntactic sugar in these accessors to handle primitive types more gracefully.

// Boolean
get aBoolean() {
  return this.hasAttribute( 'a-boolean' );
}

set aBoolean( value ) {
  if( value !== null ) {
    if( typeof value === 'boolean' ) {
      value = value.toString();
    }

    if( value === 'false' ) {
      this.removeAttribute( 'a-boolean' );
    } else {
      this.setAttribute( 'a-boolean', '' );
    }
  } else {
    this.removeAttribute( 'a-boolean' );
  }
}

// Float
get aFloat() {
  if( this.hasAttribute( 'a-float' ) ) {
    return parseFloat( this.getAttribute( 'a-float' ) );
  }

  return null;
}

set aFloat( value ) {
  if( value !== null ) {
    this.setAttribute( 'a-float', value );
  } else {
    this.removeAttribute( 'a-float' );
  }
}

// Integer
get anInteger() {
  if( this.hasAttribute( 'an-integer' ) ) {
    return parseInt( this.getAttribute( 'an-integer' ) );
  }

  return null;
}

set anInteger( value ) {
  if( value !== null ) {
    this.setAttribute( 'an-integer', value );
  } else {
    this.removeAttribute( 'an-integer' );
  }
}

These also have the nice side effect of presenting a null value when the attribute/property is not set.

Web Component attributes cannot be complex objects, but that does not mean that properties cannot. If you want to handle a Date object for example, you can add access methods. The implementation of those methods will change the internal state, and update the component.

get aDate() {
  return this._aDate;
}

set aDate( value ) {
  this._aDate = value === null ? null : new Date( value.getTime() );
}

For now though, let us get back to our label.

Web Components having slots is important for composition of content - just as most HTML elements can contain other markup. In the case of a Label the content might be a long form description. An actual paragraph would be hard to read as an attribute. There are times however when the content you want the label to display is relatively short - most application labels come to mind.

If you are inclined to add an access method for a text attribute, then you are on the right path.

We also need to observe the changes to that attribute using the Web Components API, and apply changes where we want. In the case of the paragraph element, that looks something like:

static get observedAttributes() {
  return [
    'text'
  ];
}

attributeChangedCallback( name, old, value ) {
  switch( name ) {
    case 'text':
      this.$label.textContent = value === null ? '' : value;        
      break;
  }
}

You have to be careful here, though. If this.$label points to the p element, setting the textContent will remove the slot element. While that works, it is not particularly friendly. We want to allow developers to use text as an attribute and a property, but also compose the content should they so desire.

What I like to do here is put a span inside the p, and have this.$label point to the span. If you want things really tidy, you can even add a splash more CSS to hide the span if there is no text property.

:host( :not( [text] ) ) span {display: none;}

Okay, but what does all of this have to do with a Label component in a design system?

If I set the text property, I treat that as a signal that the component will be updated dynamically at runtime. If the text content is composed (inside the component markup), then that is a signal that the content will not change at runtime.

<!-- Will not change -->
<kh-label>Hello world.</kh-label>

<!-- Will change at runtime -->
<kh-label text="Hello world."></kh-label>

This becomes manifest in the code as well. I am never thinking "Should I be using textContent here?" Programmatically, it is always label.text.

const label = document.querySelector( 'kh-label' );
label.text = 'Hello, Kevin.';

I use this pattern throughout my components. I lean on composability where possible, but if an element is going to change at runtime, I provide a means to use a property (without damaging slotted content if I can help it). With a Button component as an example, I provide a label property that can be set dynamically at runtime. If I am reading the markup, and the Button component has text content between the opening and closing tags, then the label of that button will not be changing at runtime. When I am updating the label of a button at runtime, I always use Button.label.

Next Steps

Where this really starts to get interesting is in more complex controls such as a list. Differentiating a Button from a Link and presenting an anchor element in place of the button element when an href attribute is present is another fun example. I will cover these in future posts. Until then, feel free to check out my complete Web Component template on GitHub.

Warp Test Drive

2025-10-21T00:00:00Z

Is it vibe coding or vibe debugging? Is AI assisting you or making you lazy? Is the industry shutting out junior developers or making them more productive more quickly? These are hard, often philosophical questions. Once thing is sure however - AI is here to stay. Refusing to acknowledge AI, and to learn how to use it for your workflow(s), is putting your head in the sand and ignoring the inevitable.

That is where my experiment with Warp began - somewhere between curiosity and skepticism.

Some Background

I first got to work with AI back in 2017 while at IBM. Back then we did not really refer to it as AI as much as machine learning (ML, or AI/ML at best). IBM Watson provided various ML-oriented services, and we developer advocates were first on the ground to teach other developers how to use those services. This included everything from transcription and sentiment analysis to image recognition, and even building custom models.

Fast forward to 2022 while at Amazon where I managed the documentation team focused on SageMaker (custom ML models). Of course ChatGPT launched in 2022 as well, and generative AI in general began its explosive adoption rate. Technical writers generate text, too, so we were very interested in what these new tools could do for us. We were not about to send documentation for unreleased product to a public API, but when Amazon Bedrock was released, providing data protections, we jumped at the opportunity.

With collaboration and input from a team of technical writers, I built tooling that leveraged generative AI from the ground up to see what we could do. Ownership was eventually handed off to an engineering team who scaled the project across the 200+ organization of writers.

More recently, in a freelance capacity, I have gone deeper into generative AI for my customers. This work has included vector and graph databases against custom datasets, as well as agentic tooling such as n8n. Along the way, I have used ChatGPT and Claude Code extensively to help me with complex algorithms, and even to scaffold projects and features.

I have a lot of opinions on my exposure to all these technologies, but that is not the point of all this background. The point is that I have a broad experience with both generative AI as well as ML, both from a user and implementation perspective. I recently had the opportunity to bring that significant practical experience to kick the tires on Warp’s Agentic Development Environment.

Full disclosure, I am actively seeking new work. If you find any of this background inline with what you need for your organization, then feel free to reach out on LinkedIn.

Moving at Warp Speed

Warp calls itself an ‘agentic development environment’ - which means it does not just execute your commands, it helps you decide what to do next.

Warp surfaces as a replacement for your terminal. Warp allows you to interact with the command line like you would with any other terminal. When Warp detects natural language it switches out to a generative mode. The default settings choose a model and approach that is most efficient, but you can choose your own adventure as well for those times you need more reasoning from the model. Features and settings abound to let you customize how Warp interacts with both you the developer, and the underpinning models.

Hiring Challenge

To get started, I used the Warp "hiring challenge". The hiring challenge presents you with a data file of space missions. The data file weighs in at over 9 Mb, and contains over 100,000 missions. The columns for each data row are separated by a pipe | symbol, but there are comments and other labels in there to keep things interesting. The objective, as outlined in the challenge description is to use Warp to generate an AWK command to parse the data file and determine the security code of the longest successful Mars mission.

Here is the thing though... The description reads like a product requirements document (PRD). My first instinct then was to clone the repository and tell Warp to deliver on the PRD. This worked out well because when you first install and run Warp, and head off to start a new project, you will be given the opportunity to do just that - import a repository. Warp automatically read the PRD, and got to work on generating the AWK command. Along the way, it checked itself too, which is reassuring. A few minutes later, I had the command and the desired output.

Well, um, that was easy. Suspiciously easy.

Going Deeper

While I have run across AWK before, I would never claim to be an expert in its syntax, so I asked Warp to generate a Node.js file that would complete the challenge. Again, a few minutes later, I had what I wanted in a language/syntax with which I was familiar.

In reviewing the code, I found it to be complete and comprehensive. It was not quite what I would have written myself, but I appreciated the nod to async/callback processing given the size of the data file. I ran the script and was presented with the same answer as the AWK command.

At this point, I had clicked a few buttons, and run a few commands - easily toggling between natural language and classic CLI along the way. I had spent about thirty minutes (including the install and sign up), and had set aside an afternoon. Time to ratchet things up a notch.

More Complexity

If I really wanted the answer presented by the PRD, then I would import the data file into a database, and use the magic of SQL to dial in an answer. Okay, Warp, generate a Node.js file to put the missions into a SQLite database. And it did. It even installed a modern library to work with SQLite. I ran the script, and moments later had myself a nice little SQLite file. I opened up TablePlus, and ran some SQL. Yup, same answer. All systems go.

I do not know why, but I chose to write the SQL by hand myself. Old habits die hard? Scared of being confronted with the reality that the tool was killing what took me decades of experience to learn? Denial?

I had not hit a roadblock yet with Warp. It had even gone above and beyond in some cases. It is not a real test until you have broken something, so time to get back at it. If I had a database, I figured I might as well take the next step and turn it into an REST API. I wanted to dial up the specificity a bit so I asked Warp to generate a serverless function to be deployed on Netlify.

Warp did deliver a serverless function, and that function worked, but it was an older, non-ESM, implementation. It also did not take into consideration any CORS and/or bot handling. I did not ask Warp to do that, so not really a big miss, but it opened the door to push the edge a bit more. Rather than iterate through these changes, I pointed Warp to an example Netlify serverless function I had from another project. Warp adapted seamlessly.

Okay. This is just too fun.

Since I am ultimately looking for a specific answer, not just a data dump, we are going to need some sorting and filtering URL parameters. What say you, Warp? Yeah, no problem. I deployed and hit the API through the browser, added my sort and filter requirements, and just like that I had the same answer staring at me from the first row of the JSON results. Well, I guess the only thing left is a UI.

Home Sweet UI

Having spent 15 years at Adobe, most of that time spent teaching developers to implement cutting edge user interfaces (with Flash, Flex, and ultimately web standards across devices), user interface development and design is a bit of a sweet spot for me. It feels comfortable. It is the basis of what enabled me to build the generative AI tooling at Amazon. My first role at IBM was actually testing developer SDKs for completeness and idiomatic usage across Android (Java) and iOS (Swift).

Svelte 5 makes for an interesting test for generative AI solutions. Svelte 5 was released just around the time of some of the major cut lines LLMs. Features have been added since then some LLMs simply do not know about. Also, I wanted to play with some of those new features myself, so I headed down the Svelte 5 path for this project.

I implemented the UI myself, again wanting to experience these new features first hand, but I now found myself confidently asking Warp for code snippets whenever needed. Warp had become an ally. The assistance I asked Warp for ranged from building the REST URL dynamically from user interactions, to one-liners around media queries and other markup that I was too lazy to research myself.

When I went to build the Svelte project, I needed to change the adapter for my static SPA approach. Warp handled that for me without a problem. Check out the final results. The application is responsive, supports mobile, and includes sorting on columns, as well as status filtering.

What Was Missing

I know that I barely touched the full capabilities of Warp. I will be honest, I was expecting it to bomb. It just kept getting better. Hindsight, if I had expected Warp to be this good, I probably would have just written PRDs for the various features I ended up building, and then had it generate the implementation. My experience with other generative AI tooling for developers had taught me that was a bad idea, so I went at the challenge piecemeal. I still got across the finish line, and in record time with a code base I trusted, but it would be an interesting experiment to try PRD-driven development.

The feature I found that I wanted but that was not there is the ability to use local LLMs. There is a lot of really innovative work going on outside the big players. There are features provided by open source LLMs, such as image generation, that I think would really round out the experience. For enterprise or privacy-conscious workflows, such as the generative tooling I made at Amazon, local LLM support would be a game changer.

Final Thoughts

In the end, I did not really use the "agentic" aspect of Warp. Warp was fast enough, and complete enough, and accurate enough, and this project was small enough that it never really surfaced as a need. That being said, when I think of agentic workflows as presented by tooling such as n8n, I think there is a lot of room for Warp to expand. Warp sees the input to an agentic workflow as a prompt. There is no reason it could not watch files, directories, support tickets, etc. and get to work without me needing to prompt. Put together with local LLMs and I could see tasks like product image resizing, icon generation, etc. without additional token costs.

All in all, Warp is a fantastic improvement to my experience with other generative AI tooling. If you are looking to pull your head out of the sand and get acclimated to this new AI-powered future of development, you do not need to look any further than Warp. Personally, I came expecting a terminal replacement with some AI bells and whistles. I left convinced that the future of development is not about AI replacing us - it is about AI working with us. Warp gets that balance right.