Porttitor rhoncus dolor purus non enim praesent

Almost universally the first thing every new manager does is set up recurring 1:1’s with their team, usually weekly. It’s so default in the job, HR and management books will even tell you to do it. Ignore them. Because what also happens by default is you kill your calendar, and your teams, while that time quickly devolves into project status updates and social sessions. There just simply isn’t enough stuff to talk about on a weekly basis if you don’t fill that time with project updates and what you did on the weekend.

It’s better to think of 1:1’s as a tool to be used. A tool to help you develop your team and diagnose and unblock interpersonal problems (us humans are fickle, complicated creatures!). Use it when you need it - in some situations that might be more than once a week, and in others it’s much less frequent.

“But I want to be available to my team!” - Why do you need a recurring meeting for that? Just be available and encourage them to talk to you when they want/need to.

“But I won’t know what’s really going on!” - A series of 30-60 minute meetings with each person on your team seems like a horribly inefficient way to get this information. Look for better ways.

And discussing any project work in 1:1’s is equally inefficient. By definition they’re closed door meetings, with non-visible agendas. Project work is team work! Have one meeting with all the relevant people, don’t play telephone from 1:1 to 1:1.

One director with a pretty large team we know has no scheduled 1:1’s. He just keeps a spreadsheet of when he last talked to someone 1:1 and checks it every so often to make sure he doesn’t go too long without talking to them again. No clogged calendar, more time to focus, no having to juggle day’s full of 1:1’s to make room for other things to get scheduled, no more skipping them all the time and leaving a bad taste in someone’s mouth. This works because his teams know they don’t need to wait for a scheduled meeting to talk to him, then can just talk to him. And he’s available because his calendar isn’t clogged with 1:1’s.

Say it with us, 1:1’s are a tool, not a rule!

This is why we built our 1:1 tool into KATA, and why it doesn’t come with scheduling functionality! You can add to a 1:1 agenda with someone from anything and anywhere in KATA or Slack, so that you can have a data-driven conversation and avoid devolving into a social call. And only schedule it when you have stuff to talk about.

1:1's are a tool, not a rule

Okay we’re going to try and walk a tightrope here and avoid talking about capital letter development methodologies or giving history lessons. Let’s talk about the standups of today. For a group of people who live and breathe optimization and efficiency, they’re incredibly inefficient! By definition they’re repetitive, what did you do yesterday, what are you doing today, wait didn’t I tell you that yesterday? And no one is standing! Which is a cute way to say they very rarely only take 15 minutes. Not to mention the guaranteed context switch daily. Add that up across your team and it’s a lot. So why do we even do them (besides being creatures of habit)?

They’re occasionally great, you find out your teammate is stuck on something that’s a quick solution. You hear someone is over or under engineering a problem, or had a misunderstanding of what was needed, and can help course correct. Someone is finished early and you can work with them to find the best thing to dive into next. And of course it’s nice to interact socially a little. But the bulk of the time is spent regurgitating information already in the tools, or just “still working on”. Some teams have switched to doing them in Slack. You trade the social interaction and the quick question asking for a little more async. But are people reading them at this point or is it an exercise in writing and satisfying the inner micro-manager in our head? .

Without getting too heady about it, here’s what we’ve found to be a better way. For most teams in a steady state, weekly written updates are way better. There just simply isn’t enough to always talk about daily, whereas weekly they’re just more meaningful. People are more thoughtful about what they’ve done and are planning to do, phrasing things more in business value terms not tasks or implementation details. And it’s a good forcing function to think about your week, not just the immediate task in front of you.

So let’s talk about the downsides. Early blocker/rabbit hole detection is a big one, someone could be spinning for a whole week. A better solution here is the notion of a 

Get a Slack channel set up for your team where it’s free reign on big and small problems, just post away. Alignment is actually better done on a weekly basis anyway, day by day details aren’t as good at shedding light on most of these types of problems, they get lost in the details. And you can usually tell when people are wrapping things up early from their weekly update too and just have them ping you/ping them if it’s not already obvious 

. And social time? Schedule a game night.

So should you never do daily standups? Au contraire they do have their place. They work really well at times when things are not in a steady state, when there is truly meaningful daily change in the system. And they’re another tool to help communicate and create this urgency with your team too. Whether it’s a critical time of the year and you have a big effort, or there’s a must ship project that’s key to the business. Save your daily standups for those and give your team more time for building in between.

And if you’re looking for a good way to facilitate all of this, we built the teams feature in KATA to operate exactly like this. Get weekly updates posted from team members, memorialize them for them (side benefit, very helpful for performance review season!), and let KATA fill in the details from all of the connected tools during the week.

Daily standups are a literal waste of time

Being an engineering manager can be very stressful. It's a position of very high responsibility and, well, let's be kind and say 

 autonomy. The concept of the bullshit umbrella is very simple: craziness happens, and as your team's main interface to the company it's very much up to you to decide what to say, how to say it and how much detail to go into.

 is shielding your team from everything you possibly can. Creating an environment of sanity, consistency and calm where work is planned properly at a set cadence, delivered without too many incidents and priorities do not shift. To be maximum umbrella you will need to fight against incoming requests. You'll certainly be perceived as being inflexible and impractical by your peer group, and by product and business partners. This will not be great for your career, and ultimately isn't great for your team, as to a large extent your reputation is their reputation.

 is being a transparent proxy. You say yes to every new incoming thing, no date is set in stone, you have no agency over priorities. Software delivery will suffer because individual and team focus will move around rapidly. Frustration within the team will increase as things are left incomplete and anything that does get finished will be rushed out. You won't have to argue or make compromises around incoming work as you just say yes to everything. Short term this might work out for you, but the drop in output and inevitable staff unhappiness will bite you.

As with many things the correct approach is in the middle somewhere. Teams need stability and consistency but businesses need to change approach sometimes, often at short notice.

My preferred technique with my teams has always been to be honest about where the business is, what it's doing and what it's prioritizing. If you talk about that enough, while people may get pissed off that a priority change wasted some time, they'll at least understand why.

Outwards and upwards it's more a game of compromise. If new requirements can be fit into existing work that can help. If not, you need to barter a little. Help someone out this time and they'll help you in future. At the very least, saying "no" is  easier if you previously said "yes".

And remember reputation is important, especially at larger companies. Your reputation and your team's reputation will become aligned.

The bullshit umbrella

A handy rule of thumb when creating or refactoring teams is to think about 2’s. Each primary domain should have 

 two people as primary points of contact, and no person should be a PoC to more than two things. How you define a primary domain is up to what you own, it might be a full platform like Web, iOS, backend etc. or modules or services within those. Point being two primary PoC’s keeps things unblocked (time zones, time off, meetings, team changes etc.) and no more than two areas keeps people focused and not overloaded.

Not everyone needs to be a PoC but mapping this out for future growth is also a good way to stay on top of current and future areas of expertise and make sure your team stays durable.

The 2x2 rule

A trendy but misguided “management book special” leadership style, it’s like pretending magic is real. Servant leadership says a leader's primary purpose should be to serve the growth and well-being of their team. Spot the problem? It’s subtle, sorta. Getting your team to be all they can be is great, having psychological safety is important, as is feeling supported, encouraged, and happy. But where’s the direction and alignment? The pace setting? The hard decision making? Who’s going to give critical performance feedback?

Take your favorite sports team. If the coach made sure all of the players had everything they needed, felt really glued together on the team, were happy and excited, and then just sent them all onto the ice or field, what do you think would happen? What about the strategy and play calling? Think the team will just figure it out? Well what happens when players disagree on it? You see where this goes.

Remember your job, build effective and durable teams. Effective teams need more than Kumbaya, there’s hard decisions and critical tradeoffs to make, and durable teams need a purpose and direction. So it’s not that the intention is bad, it’s just not the primary purpose. Another way to say it is that it starts with the word servant, not lead. So forget servant leadership, unless you're vying for the boss of the year mug at the team gift exchange this year.

Hire Smart People And Get Out of the Way:

This one has been written down already so we won’t restate it, check it out 

Beware the soundbites

There are hundreds of books, blogs and training courses on how to be an effective manager. How to delegate, how to coach, how to verify information. Less has been written about the role of Engineering Manager, which as part of software R&D teams has a particular set of established techniques and processes the everyone is aware of but have different feelings about.

The main thing to understand is, part of leading is deciding how to lead. Just because you've always done standups a certain way, taken half a day per sprint to plan things in detail, had standardized kickoffs or checkins with product and design folk - this does not mean you have to continue doing things that way. Even the choice of whether to work in a strict scrum / sprint format or something looser is ultimately up to you*.

Your job is optimizing the productivity and morale of your team. They are the constant factors, and everything else is a variable.

*you may not have this flexibility at all companies as a brand new manager - some insist on proscribed processes. But once you get established you can absolutely argue for and make changes. The job is not about standardization, it's about shipping stuff. In these places, try to understand 

 they like to standardize and make sure whatever you propose addresses that.

Managing Upwards & Outwards

You Decide Which Tools To Use

Volutpat commodo sed egestas egestas frinlla phasellus faucibus

Skip recurring meetings from time to time, you’ll find out if they really matter

. More often than not we go to a meeting simply because it’s on our calendar, not because we need to. And as a manager you’ll get added to a lot of meetings. Try experimenting with not going from time to time and see if anything breaks or changes. We bet it won’t more often than it does.

Never create a meeting with unlimited recurrences

. Similar to just going to a meeting because it’s on your calendar, don’t be guilty of making these either! Pick a number of recurrences and then let it drop off. Either you’ll notice immediately because it was so valuable, or you won’t and now you just saved everyone a bunch of time.

Office hours are a great way to handle infrequent but important time asks

. It’s just so much easier to work more async as a team when you can clearly see what’s on a calendar. Especially for grabbing quick working sessions (our favorite kind of meetings!).

Fun sayings you can use to skip/leave/end meetings

Keep it great, make it less than 8! (attendees)

When your part is done, make a run! (feel free to leave early)

When the meeting’s over, end the meeting! (doesn’t have to fill the allotted time)

. Just make them working sessions. Clear calendars leave time for collaborative work. Don’t villainize meetings on your team, people won’t schedule them. Encourage clear calendars to work together on issues of the moment.

The Surefire Trick To A Long and Stunningly Successful Eng Management Career

Pro Tips On Time Management

Make more time for meetings. Wait…. what?! Yeah you heard me, you need more meetings and you need to make time for them. And while you’re at it, write longer emails too please. And more docs, that’d be great. Thanks!

Seems antithetical in this era of teams being squeezed to the breaking point for efficiency, headcount reduction, more distributed than ever, and being told they need to figure out how to actually get MORE done than before. Then Shopify publicly canceling all meetings and people riding that bandwagon. But as a recovering engineering middle-manager I want to let you in on a little secret. Meetings aren’t bad. They are great in fact. They’re just used really poorly by default in most organizations.

A duel of words… people love working sessions. We have a hard problem to solve, let’s lock ourselves in a room and not come out until we’ve solved it. It’s fun, we’re accomplishing something together! But meetings? Nah, that’s the let’s listen to Bob run through the 32 slides we’ve already read on content we know, or let’s all go around the room and give our update while everyone zone’s out until it’s their turn. Finished our agenda early? Doesn’t mean the meeting is over, it’s scheduled for another 27 minutes. At least it’s usually Zoom now so you can get some laundry done during it.

The crux of the problem is that fast-moving engineering teams have a really hard time staying in-sync whenever you have more than a small team working on something. So we resort to expensive human time to force it, at the risk of being misaligned and inefficient. It’s hard to trust without the verify. And we don’t question it because that’s how it’s always been. Daily standups for engineers, weekly status meetings for managers, monthly business reviews, quarterly OKR reviews, yearly or worse planning sessions. I always chuckle at the adage “Plans are useless, planning is priceless”.

It’s part human problem, and part accepted cost of doing business. Which is terribly ironic given we’re the part of the organization that builds innovation and new efficiencies for everyone else!

Make more time for meetings, the good kind. By canceling the bad kind, recurring update ones. Hard to schedule a working session when you’re triple-booked 3 weeks out. Write more i.e. more async. Random Idea: I think a calendar tool that made you write an explanation to your boss anytime you made a meeting recur would go a long way to improving eng org efficiency.

How do you cancel recurring meetings and work more async? Adopt a system where you don’t need to have a recurring meeting to stay in-sync and move things forward. Something that can extract the signal and make sense of all the noise across all of the tools. Save the time for actual collaborative working sessions not updating or information hunting. Shopify has one, they built it out of necessity. Most other iconic companies do too, they realized they needed it along the way, that’s a big part of how they scaled. And if you’re not in a place where you can build your own, we built one for you. We think it’s pretty good and would love for you to try it out, it’s called KATA.

And if you lead a bunch of people and this sounds a little scary to you, just know that NVidia, the most recent company to hit a $1T market cap, doesn’t have status updates, and the CEO doesn’t do 1:1’s. They have a clear system for seeing progress that he stochastically samples and progress is clear to everyone. If they can do it, so can you!

So here’s to getting back to building. Meetings are dead, long live meetings!

Meetings are dead, long live meetings!

It's well documented that the pandemic-induced remote work trend has led to globally distributed teams working more asynchronously than ever before. Less well understood is the impact this has had on the way engineering teams operate, taking something that was already quite difficult - staying aligned across fast moving, autonomous software development teams - almost unmanageable in many cases. Despite having more tools, teams, metrics, and frameworks at their disposal to help teams go faster, somehow it’s getting slower to build and ship products.

In today’s business climate, execs are asking their engineering leaders and managers to meet the same business, technical, and quality objectives with fewer resources, tools and support roles. This “do more with less” mandate puts intense pressure on the middle layer of engineering management. Their teams, more async and distributed than ever, have doubled in size while supporting resources have been cut in half. So bogged down by the time required just to maintain visibility into what’s going on that there is no time for anything else.

Stop for a minute and add up all the time and energy that engineering managers spend tactically gathering the intel they need to triage issues and manage their teams. Think about the tedious work required to stay on top of how a project and teams are doing, identifying friction, and taking action. Days are wasted chasing down project updates, scheduling meetings, bugging engineers, and sorting through Jira tickets and GitHub PRs to figure out where the bottlenecks are. Buried in the trivial details crowds out the time needed to ideate, plan for, and push through high-impact initiatives.

Now consider the impact it would have on engineering managers to keep them focused on execution and strategy. Or consider the costs if you don’t. Organizations that don't find process and execution leverage for their leaders will become ever more reactive, slowly losing talented managers that get burnt out spending all their time managing information and not enough time driving execution.

Imagine if you had all the information and insights at your fingertips to debug the execution of projects and team in minutes without the unnecessary meetings, ceremonies, disruptions, and tools previously required to get it. You’d get to spend less time managing coordination, alignment, and status across projects and teams, and more time keeping them moving forward by resolving issues, mitigating risks, and accelerating decision timelines. As a more proactive manager with a more productive and collaborative team, you'd effectively unlock a new gear.

This is where KATA can help engineering leaders & managers by putting the focus back on execution. KATA is the leading Engineering Execution Platform, equipping managers with the just-in-time insights to debug progress across engineering projects and teams. All the intel you need to help your team go faster is never more than a click away. Go as wide or deep as you need, whenever you need to, absent the unnecessary meetings, ceremonies, disruptions, and tools.

Interested in seeing how KATA can generate the leverage you need to unlock a new gear for you and your team? Take a product tour to find out: 

Searching for leverage in all the wrong places

Felis donec et odio pellentesque diam

In the current macro climate, the mandate to engineering teams is clear, do more with less. Leaders are under significant pressure to maintain, if not increase, performance while simultaneously cutting costs. This leaves them canvassing their tools and teams to identify opportunities for operating leverage. One area that deserves real scrutiny is the bloated engineering project management stack. Teams can no longer afford to waste money and time trying to bandaid over the shortcomings of products that were designed for a different era.

In 2023, a modern project management platform should demand less time/energy from the organization to do its job so the team has more time to do theirs. It should automate all the coordination, alignment, and status update overhead that's built up in your organization so the team can spend more time building and shipping killer products. Stated simply, 

Concretely, for project owners, project managers, ICs, and leaders, this means a modern project management platform that enables…

 licenses (needing visibility into what's going on shouldn't require a license to every tool)

 people to coordinate, manage, update, and communicate all of the above

In a perfect world, project management tools are supposed to efficiently communicate (across various mediums) what's going on with a particular individual, project, or team. The idea is that if everyone can efficiently stay aligned with what's happening and why without slowing down, the collective group can move faster. They quietly wrangle all the information that informs what's going on into some consistent and accessible format that can be updated and shared on-demand. But the current state of engineering project management tools is far from perfect.

 Teams are still suffering indigestion from the SaaS sprawl of the last few years. With so many different tools deployed across the organization, extracting a singular view of what's happening is nearly impossible. Every team has their preferred set of tools. Rarely do tools span departments. If you want to know what's going on outside of your team, you need a person to help chase down status for you or a license to dig in and do it yourself. In the latter case, you probably don't have the time or expertise to efficiently navigate the tool to find what you are looking for. Never mind that provisioning a license to you for this purpose is not a good use of money. Nevertheless, it's faster to provision someone a seat and wish them well than it is to track down the information they really need and convert it to a format they understand. So here we are.

 It's well documented that the pandemic-induced remote work trend has led to globally distributed teams working more asynchronously than ever before. Less well understood is the challenge of keeping an organization coordinated, aligned, and moving fast amidst this transformation. Armed with project management tools designed for a different era, the people responsible for helping everyone stay on top of what was happening were ill-equipped to do so. 

The organizational response to the above dynamics has been to build out teams, acquire more tools, and establish a series of rituals, processes, and meetings to manually close the information gaps. And while everyone now has a project management tool, they still can’t easily answer the most frequently asked question of a project or initiative, “How’s it going?”

The bar is clearly higher these days for which tools make their way into the engineering toolbox, although, given the dynamics above, it seems that it’s not high enough for project management.

Interested in demanding less (overhead) from your project management platform? 

 to evaluate KATA, and free up your team to get back to building.

Engineering Leaders – It’s time to demand less from your project management platform!

What are the critical discussions to be had & decisions to be made?

There have never been more tools, metrics, task/activity/issue trackers, performance frameworks, and data at the disposal of engineering leaders, TPMs, and delivery managers, yet when key stakeholders want answers to any of the questions above the most frequent response is “Let me get back to you” followed by a series of slack pings, status check-ins, quick sync meetings, and a frantic search across tools, threads, and artifacts for any indications of progress.

To achieve alignment up, down, and across the team, this ad hoc cycle repeats itself as many times as necessary. More often than not, the task falls to project owners, TPMs, and Delivery Managers to brute force their way past the many 

 of their existing project management tools in order to provide answers. Unfortunately, servicing each request is not a write-once-send-to-many operation. It’s often a custom response, manually curated to the unique needs of the individual making the request. Worse yet, the information gets stale fast. And while activity data from various tools can help piece together some indication of where things are at since the last check-in, the truth most often lies in the human context (e.g., decisions, demos, discussions, escalations, etc.) that gets buried in email, slack threads, and documents. 

Complicating things further is the rapidly evolving nature of how and where work gets done. Fast-moving engineering teams are more autonomous, distributed, asynchronous, and in this macro environment, resource-constrained than ever before. Updates are no longer a shoulder tap away…not that anyone liked that tactic anyway. And engineering teams can no longer afford to keep adding TPMs to try and close the information gap caused by project management tools designed for a different era.

As projects, and the people working on them, get further dispersed across a widening combination of locations, time zones, and tools, there needs to be a better way, a modernized approach to project management designed for the realities of today's engineering organizations. In other words, 

Project Management Without The Management.

Modern project management solutions sit above the activity/issue/task tracking tools you have in place today, combining data and human inputs together to deliver the four highest value aspects of project management in a single platform:

Most importantly, they do it without the tedious 

 required to obtain, maintain, and communicate the same information from other tools, systems, and processes. Less disruptions, check-in meetings, rework, and double entry status bookkeeping.

For the project owners and project managers in your organization including Engineering leaders, Technical Program Management and Delivery teams, a project management tool should be the single source of truth for answering the most frequently asked questions of any project or initiative. Pulling from your preferred tools, including existing project management tools, task managers, and issues trackers, a modern project management platform combines work activity data, artifacts, and critical human context into a central hub of progress that increases visibility, accelerates alignment, and improves decision-making. Best of all, by supercharging your project management capabilities, your engineering team can get back to focusing on what matters most, building better software, faster.

Interested to see what modern product management looks like in action? 

 for the KATA Early Access Program today.

Every engineering team has a project management tool, so why can’t they easily answer these 5 questions?

Technical project managers (TPMs) get a bad rap. Below is a collection of engineers favorite "pings" they receive from TPMs on a daily basis. 

Please edit the three spreadsheets that are somewhere in one of 100 teams chats I told everyone about 6 weeks ago when you were on holiday even though we have a ticket system and confluence.

As evidenced above, PMs take a lot of flack from engineers. But continuously tracking, communicating, and updating the status of a project across a large and fast-moving team is hard…and it's not getting any easier. The rapidly evolving nature of work has resulted in engineering teams that are more distributed, asynchronous, autonomous, and resource constrained. Individually these are each meaningful shifts in how work gets done. Collectively their impact is seismic, yet the tools used to help teams stay coordinated and aligned have barely changed. So it's no wonder PMs have struggled to keep up. They've been showing up to the project management knife fight with a squirt gun.

With traditional project management tools, the value you can get out of them depends entirely on what information you manually feed into them. But tracking down all the activity and progress indicators requires a lot of heavy lifting and constant nagging (which no PM enjoys). So, to keep the inputs fresh, they default to the dreaded triple crown of status management; check-in meetings, slack pings, and spreadsheets. The collective goal of these rituals is to get the information you need to communicate status on demand. But unfortunately, the information gathered quickly becomes stale, triggering another cycle. Wash, rinse, repeat.

There needs to be a better way. Project management software should empower PMs and the engineering teams they support, not the other way around. Imagine a modernized approach designed for the realities of today's engineering organizations. Imagine a platform that takes care of the grunt work so a PM can free up to focus on the good stuff, like making decisions, removing blockers, mitigating risks, and shipping killer products. Imagine a super-assistant that automatically collects and curates all project activity data, artifacts, and critical events (demos, decisions, etc.) into a central dashboard for you. Imagine a single source of truth for communicating what's going on with any project or initiative. The never-ending cycle of disruptions, check-in meetings, and status pings from your PM become a thing of the past. That's modern project management.

So the next time someone starts using PMs as a punching bag, no matter how funny the .gif is, remember, don't hate the player; hate the game. It has been a game they've been set up to lose all along…until now.

Interested in modernizing your project management capabilities? 

Don’t hate the player, hate the game

You wouldn’t fire your mom! But there’s hard decisions you have to make leading teams. While it’s enticing to think of your team like a family, people who you forge lifelong relationships and bonds with, the reality is that’s just not the case. Teams are composed, come together, and break apart over time.

. And you’re the composer. One of your many jobs is to figure out how to compose the right team for what you need to accomplish right now and how to adapt that into the future. Whether you're thinking in terms of 

Cringley’s Commando’s, Infantry, and Police

, the composition of the team is your job.

You’ll have many constraints and obstacles (headcount budgets, your company’s reputation to attract talent, internal talent mobility etc.) but above all else do not be a victim to your circumstance here, team composition is your most important lever. So important that the next point here also deserves its own section…

It's a team, not a family

Hiring is your job, not the Recruiting team’s job.

Hiring is your job

There’s many tomes written and venture dollars lit on fire around culture. We won’t go far down this rabbit hole, save to say remember that culture is a consequence not an output. You can rarely affect it in the way you think; words can ruin it but they don’t make it. Actions do. And your teams will be a combination of your company’s culture and your actions. So don’t overthink this one,

Remember, engineers have off the charts BS detectors and will smell inauthenticity a mile a way. If your leadership style is to be a transparent proxy to your boss people will know. It’s not weird to think 

, because it is, that’s the job. And by being authentic, making it clear what you care about, where your red lines are, you set your team up for autonomy and speed. They can make more and more decisions in your absence because they know how you think about things.

Building and Leading Teams

You’re going to have to make hard decisions and deliver tough news. Even when you might not have made the decision yourself. That’s an unavoidable part of the job, you’ll be held to account on that. But the control you have is what comes before that tough news. It’s very tempting and easy to always frame things in the positive to people. To give false hope, whether it’s explicit or implicit. You might not even realize you’re doing it. But it’s one of the worst things you can do, it’s truly a disservice to the person and it’s a failure of your job. Short of broad company action, terminal news should never be a surprise. That’s on you.

No surprises

If you found out your boss didn’t trust you for the last year you worked together, wouldn’t you feel like a bit of a patsy? That thing you were working towards, your growth plans, even the nature of their interactions with you. What an empty feeling. So don’t do this to others. If your trust in someone is truly gone, then you have to act. It might mean another team or another company, that’s situation dependent and based on the reason the trust is lost. But no matter what you have to make a change.It’s unfair not to, it’s about you not them. Their ceiling is in place and they don’t even know it.

When trust leaves so should they

Performance management is simple and difficult by turns. Expectations are easy, delivering feedback and assessing change is hard.

At it's most basic level, you should demand three things from everyone:

The first is the functional parts of the role: write the good code. Make good decisions about design. Review code in a way that educates. Pass your knowledge on well. At more senior levels, demonstrate the influence needed to get your good technical ideas adopted at scale. Make good hiring decisions.

The second is hard to measure but easy to describe. We've all worked with people who care deeply about their work: they ask good, detailed questions before writing specs or designing software; they take time to train and mentor others and feel rewarded by doing so; they have great curiosity and a desire to learn and improve; they are affronted by errors in their work; they are craftspeople. We've also worked with people who are the opposite to one or more of those things; they phone it in.

The third is pretty straightforward, but note there are different types of asshole. The judgement comes around how it affects their work (and remembering how critical team morale is). Also consider the anti-asshole behaviors: people with sunny dispositions who are pleasant to work with; people who are empathetic and take care of others; people who communicate clearly and take time to ensure they're well understood.

People are inconstant and change over time. They have lives outside work. A person may start to care less, or become withdrawn and frustrated - it's possible their emotional energy is being poured into something more important. It's your job to understand this and adjust accordingly. This is the "continual" part.

In all cases, employ empathy and ask questions before making judgements. 

Sincerity, authenticity and direct speech

How To Critically Assess Someone

Continual Assessment, Continual Feedback

First thing to say is: these assessments will become second nature to you over time. You'll develop a strong sense of where people are over and under-performing, and what expectations per level are.

The reason for that is there's no magic to it: level guides represent a fairly standard career trajectory that isn't special or specific to engineering. It's just that people took time to define it better: in an industry of engineers you shouldn't be surprised there's a push to make deterministic system from something as inchoate, qualitative and bendy as "your career".

. Learning and developing. Start building expertise in one stack, expect development in code quality and organization, good response to feedback, learns quickly. The best junior engineers are extremely keen to learn, but also able to listen.

. Workhorses of engineering teams. Consistently deliver high quality output, and will start designing their own software of increasing size and complexity. Code standards are as good as they'll ever be but breadth of experience is still developing.

. Can deliver complex things across different parts of the stack. Comfortable with product and design ambiguity. Authors complex design documents and leads reviews with technical and non-technical folk; shows consistently good judgement.

. Can deliver the biggest and most complex things, and works across multiple teams. Actively looks for new, high-leverage things to work on: technical platform, fitting technologies to business problems. Has the influence necessary to get other engineers to adopt new things.

Level guides are fine; experience is better

If the cause of low performance is not acute you can’t expect an acute change. Acute performance issues feel great to solve. Maybe the person is struggling with a personal issue and you just need to give them some time away, or there’s a misunderstanding to clear up, or something context was missing. Clean, straightforward, permanent solutions that take effect quite quickly.

But then there’s the vast majority of the rest of the cases that aren’t acute. Ones that require coaching, regular check-ins, behavioral changes, and gradual improvements over time. We all want to help these folks, we feel compelled to even, but we’re here to tell you, it’s usually not worth it. As a general rule all of your feedback, nudging, and guidance will get you a max 10% improvement over the long run. So you need to decide upfront if it’s worth it.

This may sound harsh but its one of the biggest traps of early managers fall into, believing they need to spend the bulk of their time on low performers to coach them up to be high ones. Not every person can be a high performer on every team, it’s natural. Look no further than your favorite sport, players move around to find the right team for them to play their best!

Uncover the core issues affecting the low performance and if they can’t be acutely addressed they’re unlikely to change more than 10% with any amount of effort by you.

10% is all you get

When new folks join your team you of course want to be supportive and help them get up and running, you definitely should do that. But this is also a critical time in setting up what your and the team's expectations are, what normal is, for performance. It's easy to not pay attention, or to cut a lot of slack because they're new or they're still learning. But you should be doing the opposite, paying incredibly close attention and spending extra time with this person to ensure they're off to the right start.

There's also a few helpful tips we've found:

Pay close attention to when the first PR is created. If it's in the first day or two, great. First week, okay but that's also a sign to look a little closer and understand why. Longer than the first week? An absolute sign to dig in closely and address any issues now before they become normal. 

If people are routinely taking around a week or longer to get their PR then it's more likely your problem than theirs. Fix your onboarding. (We repeatedly learn this the hard way. You think it's a one time cost but it's actually a signal of the complexity of your system and how hard it is to work in.)

Set a calendar reminder for 6 weeks after someone starts. Do your own assessment of their performance. 6 weeks is long enough to get meaningful work done, but not so long that someone isn't open to adjusting to the new team still. If it's not going well, this is a good time to make some major changes, maybe a new project or even a new part of the team. Repeat again after 6 weeks, and if it's still not working out then maybe that person just isn't a good fit.

Get it right from the start

The art of assessing people and their suitability for a role is something that you can improve at over time, but will never fully perfect. It's functionally very similar to hiring, but over a far longer period and with many more data points.

First thing to establish is the criteria. Your company may have an established ladder in which case all well and good; if not, this section will go into the basic tech roles and offer quick crib notes for over/under-performance for each.

You want to split your assessment into functional, behavioural and growth potential. You don't need to score these - this isn't a test - but you should know enough about each person to say whether they're over, under or at the functional and behavioral bar for their level, and what their potential is to grow to the next level. From assessing strengths and weaknesses you can write a good summary and provide actionable feedback.

Note that "for their level" is critical. This isn't a single stack rank; if you're comparing people, make sure you're comparing fairly.

Planning Done Right

The title of this post was a statement made to me by an engineering leader this past week. He'd recently adopted a new tool for tracking engineering metrics. And while pleased with the increased insight into things like cycle times, review times, and rework rates, he was still lacking any sense of whether all this work, regardless of how efficiently they did it, was being channeled in the right direction for the business.

Also missing were the critical details about the work being done that get buried in the cracks of various tools, threads, and docs. Here he was referring to the qualitative "checkpoints" that naturally occur in any project, like decisions, demos, discussions, status updates, and blockers. While difficult to quantify, these nuggets of context are absolute gold for anyone trying to understand how the work on a project is really going or for those needing to efficiently "catch up quick" in an async environment.

Every team we speak with struggles to capture and preserve this context centrally because doing so pulls everyone out of their preferred tools or requires the soul-crushing task of double-entry status bookkeeping (i.e., copying and pasting the same information in multiple different places). Absent this central hub of progress, engineering teams implement tactics to surface these details that often cause more harm than good. 

Finally, regardless of the metrics dashboard's usefulness to engineering, they aren't in a format easily consumable by the rest of the business. Still absent is the goal-project-work alignment that remains so elusive for most engineering organizations. This is the missing link to ensure that every layer of the org is running at maximum speed toward the intended business target. Critically, it also helps strengthen the partnership and trust between engineering and the rest of the business by providing visibility into what is often viewed from the outside as a black box.

In our frequent discussions with engineering leaders, we consistently hear slightly different versions of the same story. If you're struggling with these issues, we want to hear from you too. These are the types of challenges we're trying to address with KATA. Now's your chance to get into our Early Access Program and get those feature requests to the top of the pile!

“What good is a fast car if I have no idea which direction it’s headed?”

Name this movie: “A million dollars isn’t cool, you know what’s cool? A billion dollars.” Now just replace ‘a million dollars’ with ‘project status updates’, and ‘a billion dollars’ with ‘project demo’s’. That is an accurate ratio of their relative value.

Project status updates are curated, crafted pieces of information, written by professional storytellers. They have a role, but it’s a supporting one when way too often they’re put center stage on communicating progress. Build a culture of creating demo’s for everything your team does, they are what really should be center stage. And find a way to make sure they’re seen. Live demos can put people off, but recording one async and posting to a common place is great! They come with many benefits:

Way more interesting to consume (and if you argue they take longer try to read a project status update, and Loom et. all do auto-transcripts now)

You communicate way more, pictures and 1000’s of words and all that

There’s no crafting or curating, it is what it is.

Way better at building alignment, you see all of the details so you can catch if something is off that might not have made it into an update.

Gives your team more visibility and credit to individuals doing the work

By default forces you to think in incremental functionality which we think is the best default

Not mutually exclusive with other flavors of *DD

Not only for feature teams. We love demo’s that are just a picture of a graph showing an X to Y change. Ditto for partially working features, or prototypes, or mockups!


We think demo’s are infinitely (well at least 1000x) better than status updates so we made sure you in KATA you could post them from anywhere, to both your team and your projects, and we’d notify everyone for you! Whether you’re in KATA, Slack, GitHub or any other tool with our native integration or simple tagging language you can post your demo in context, and we’ll make sure it gets to the right place and is memorialized for later.

Demo driven development: show don't tell

I joined the Prime Video team shortly after college, back when it was still called Amazon Instant Video and no one had ever heard of it. We were moving fast, setting out to be a top streaming service (something I’m proud to have played my small role in!). As a young, ambitious, overzealous engineer I was always looking for ways to do more. We didn’t have any way to plan our sprints, or optimize our velocity I soon realized, and with that, an opportunity! Jira, surely this is the answer. After-all, how else could we be agile?

So I got it up and running, got all of our tasks in there, and even managed to snag a TV to display our board on, like an ever watching beacon of speed, above our pod. Surely I’ve done it now, I figured, look at me go! Well it took exactly 1 week of standups around that board before I had to resort to showing up at everyone’s desk 10 minutes prior to our standup asking them ever-less politely to update their Jira. And after a while of that I ditched the display saying you know what, I need more of a forcing function, I’ll make physical stickies and we’ll stand around a whiteboard and actually move them. Then we’ll never be out of date.

I’m sure this scene has played out in countless tech offices around the world: well-but-misplaced energy gushing from a young aspiring engineer-would-be manager, standing over the desk of someone decades their senior, saying would you please update your Jira or move your sticky note so we can work better as a team?

As that young future manager, having tried many versions of planning and measuring innovation on many team combinations at various companies thereafter, here’s what I’ve learned: none of it works. The reason? Software projects unfold, they’re never known fully in advance. There’s some surprise here, technical debt there, operations issue, staffing issue… always something and usually many things! So while it makes you feel warm and fuzzy when you spend all of this time and energy upfront building a meticulous and perfectly crafted plan, tasks estimated down to the day, knowing exactly what will be done and when and by whom. Only to start, and watch it all change and you have to start again. And again. And again.

In the words of Mike Tyson, everyone has a plan until they’re punched in the face.

I’m not saying there’s no value in breaking out high level tasks. Those are great, but view them as an organizing and remembering system, not a scheduling system. And this is why you won’t find tasks in KATA, we think there’s a lot of great task tools already and everyone has their favorite. We built KATA to help you get those tasks done efficiently, not spend your day managing tasks and updating tickets.

Story points are a nice story

We all know the best way to get nothing done is to try to do everything, the power of prioritization and focus. There’s many prioritization methods out there to debate with your favorite Product Manager, this isn’t about that. This is about how focus slowly erodes through your execution cycle, kind of like build times. A second here, a few more over there, all of a sudden it takes you 10 minutes to build your code, 

 Focus is the same way while you’re executing, a little change over here, a “quick win” over there. Have someone start early on a project even though they’re still finishing their last one. Before you know it you’re doing too much again, despite your intention not to.

My favorite example of this, while doing research for KATA early on, was speaking with an old colleague and friend who’s an Engineering Manager. I asked him how big his team was, 10 people. I then asked him how many projects he was working on right now, and he pulled out the project tracker spreadsheet. I politely chuckled as he started counting… 1, 2, 3…. 11, 12, 13…. 18, 19, 20!  2 active projects to 1 engineer on the team. He was shocked, he’d never actually thought to count it despite staring at the spreadsheet almost daily. He immediately knew he had a focus problem. This is how this gets you, not in the beginning of your planning when best intentions are all you have. But when you actually start executing and reality sets in. So stay vigilant my friends, you’re probably doing too much!

This is why you’ll find the board view in KATA so you can quickly see how many projects are in flight, and shortly KATA will tell you when it’s too many. We’re all guilty of it, it’s one of the silent killers of progress, so stay on guard!

You're probably doing too much

Similar to projects, teams tend to exist because, well, they exist. And they keep existing because they are always forward looking. But, not often, but sometimes, you should realize when you need to kill your team. Nuts right? It’s like saying please fire me.

In a former life I led a decently sized engineering team for one of the oldest products at our company. As a result of its age it had taken on a lot of product forms over the years, so had a lot of tendrils technically as well as organizationally. The company was also a fast-growing startup, so you know, technical debt. I truly loved that product line, it was incredibly fun to work on, and we really tried to make a go of it. But after a while I realized, it shouldn’t really exist, it had become a cobbled together frankenstein of systems and product lines. Heck we simultaneously had an ad product, a B2B product, B2C product, and an organic one. It was one of the scariest things to do but I advocated with my also brand new boss to break it up and find the right homes in the technical architecture for the product as well as right teams for the people. And as for me? I wasn’t fired, I actually moved into a larger role with a bigger team, on a much more critical company initiative. In all definitions I was 

As humans we’re hardwired for self-preservation but just remember why you joined the company. Not to make the best team, but to help make the best company. You’re part in that is building effective, durable teams. And sometimes it takes an incredible amount of maturity and courage to say the team isn’t and can’t truly be effective in it’s current form. The trick to self preservation here is to make sure to realize this before someone else does.

Be the first to realize when the music should stop

Don’t take our word for it though, here’s one of the original 

Agile is dead; long live agility!

You've probably heard those words before. They're part of the standard management vernacular. I've certainly written them several times in this guide. But what does it mean, and how can you apply it?

Simply put, trust is empowering. People operate best from a position of trust. They make better decisions, and they make them more quickly. Teams with high trust have high morale, and more autonomous, and will deliver more, better software. Added to which there is a virtuous cycle: productivity breeds trust, which breeds productivity which breeds more trust.

Sounds great - I'll let them get on with it then!

A Practical Handbook ForEngineering Management

A Practical Handbook For
Engineering Management