if you only read one thing from this post, read this: some people work slowly because they think they have to put the same effort into every item on their to-do list. I think working smart is knowing which items on my list determine the success of my project and which don't. that's it. the rest is more thoughts on speed.
I'm writing this because I often tell my team I want us to be faster, and I can tell it isn't landing. these are some of the things I think they hear when I ask them to be faster: 1) this person doesn't understand how hard what I'm working on is, 2) I can't go faster because I'll do it badly, 3) if I do it badly or imperfectly it means I work badly, 4) the way to work well is to obsess over the quality of what I do, 5) this person is asking me to do something halfway, 6) this person is asking me to work after hours so we can have this sooner.
none of those things are true. I want to write about this partly because I want to think through what speed actually means to me and why something that's counterintuitive to a lot of people feels so natural to me.
(I think I should write about why speed matters, but instead I'm going to link to when I wrote about why I think it matters to ship imperfect things. it's another way of talking about the same thing.)
why I think people are sometimes slow
1) they don't know that speed matters. my guess is that no one ever told them speed matters. probably because they come from work environments with a different pace, or because in latam there's no sense of urgency in the startup world. this week I told someone on my team they needed to solve something faster, and they said it worried them that I was asking, because it made them wonder if we were running out of money or if the company was doing badly. that read is completely reasonable, because in the latam startup ecosystem there isn't a sense of urgency. there's nobody else doing what you're doing (or building better products, or shipping features faster). we don't watch what others do. competing is kind of frowned upon (at least in Argentina). on top of that, by definition a startup is always running out of time. that alone should be enough.
2) they think every item on their to-do list has the same importance. I'll give an example: I'm trying to close a sale. closing a sale involves several steps: putting together a presentation, building an ROI, booking and prepping meetings, drafting proposals. if I think every item on this list has the same importance, I'll put the same energy into all of them. but the design of the presentation, for example, doesn't matter as much as building the ROI. one problem I see is that some people think they have to put the same effort into everything they do. I'm 100% in favor of perfectionism, but we should only be perfect about the things that matter. working smart is knowing which items on the list determine the success of the project and which don't. it's important not to give the same attention to everything, and important to develop the intuition for what matters and what doesn't.
3) they work with inefficient tools or systems. this is easier to understand when we're talking about engineering, but I think the same applies to badly designed processes. if a task takes twice as long because it eats up so much mental energy, I'm going to be slow. in code, it's easy to spot when this is happening: it's the moments when an engineer has to do a task and spends half the time deciding whether to just do it or rewrite the whole thing. in those cases it's often better to fix the system at the root so we gain speed later.
4) they don't trim, they do everything on their to-do list. years ago I was taught a system called get shit done, which says that for every task the first question is whether I can delegate it (if I can, I do); if not, can I do it in less than 5 minutes (if so, do it now); if not, schedule it; and if I can't schedule it, I have to delete it from the list, because it means I'm never going to do it. part of being fast is deleting items from the list. it's important to trim ruthlessly and trust that if something matters, it'll come back.
5) they don't break work into small units. a very common way to be slow is to waste time. and wasting time is often working on things that aren't important right now. when we look at a big project, we tend to start with the part that feels hardest. it's very important to do the opposite: start with the smallest, easiest, fastest unit to complete. that matters because a finished task gives you the energy to take on the next one. instead of starting with the big and hard, start with the small and easy (the low-hanging fruit). the other thing that matters is breaking the work into small, doable chunks. and it's important to sort them from smallest to largest (by how long they'll take) and start one at a time.
6) they think something well done is something that took a long time. I think the opposite is true: something that took a long time is often something we built under assumptions that may have been wrong. the problem with taking a long time to finish something is that we're flying blind. we won't get feedback until we have the final product. and if the final product took 3 months, it may mean we spent 3 months building on faulty assumptions. another way to think about speed is that what we're really doing is sharing our process. there's some ego in wanting to share only the finished product (we don't want to be criticized for something incomplete). it's important to work past that, because it costs you time (and it's mostly imagined: nothing lands better than the vulnerability of showing someone an incomplete product and asking for help building it).
7) they solve problems they think they'll have in the future, instead of problems they have now. the important question here is how many users we're actually going to have over the next 6 months. usually the business-side roles have an estimate. if it's a b2b business, we know the monthly growth target is 20% and that means X users a month. you build a system for that number of users. again, this is easier to think about in engineering. a tell that a dev has this problem is when they keep talking about "scaling" and justify their decisions with scale. things justified with "scale": complex queueing systems, notifications, measurement infra. obviously the line is thin between when these things matter and when they don't. that's why it's important to understand the actual usage of what you're building.
now that I've listed what I think makes people slow, I could list what makes us faster. to follow my own advice, I'm not going to. this post as it stands is more useful now than it would be after another 3 days of work. I hope it's useful as is. and I hope I'll keep learning so I can write more on this later.