A company’s overall goals can shape its culture. Take the popular “Employee of the Month” idea, when employees see it as meaningful, it becomes ingrained in the culture and can motivate higher performance.
But these goals need to be achievable, and sometimes making them achievable is a small matter of phrasing. Let me show you an example. For Canva, where I work, tenure is important. One way to celebrate tenure would be by marking when people joined. For example, a company can choose to give hoodies like this:
The problem with this approach is that it would be impossible for someone to improve in this dimension. Anyone that was hired in 2024 will never achieve having been hired in 2023 no matter what they do.
Instead, Canva celebrates Canvaversary (your anniversary of having joined Canva). It still transmit the same information: “tenure is valuable, tenure is important”. But the big difference is that every time you see someone display a Canvaversary badge with a number bigger than yours, it is a badge that you can acquire by staying around long enough. It is an achievable goal.
My laptop now has these stickers:
And I also have this beautiful pin:
Oh, and at the five year mark they make a poster of you. They are really good. I’m looking forward to my 5 years at Canva poster.
Bring your own keys into an affiliate relationship
I’m starting to observe a problem where a lot of LLM-enhanced apps are starting to pop up. For coding you have Cursor, but now there’s also a terminal called Warp and it costs $15/month. For individuals, consultants, small and even medium sized companies, this isn’t a workable pricing model. All apps were already turning into subscriptions and the cost of LLMs is accelerating that.
What compounds the problem is that, because everyone feels uncomfortable with the potential surprise high bill of pay-for-what-you-use, many of these apps are charging a single monthly fee. A simple single flat fee, except that the cost of the LLMs is not flat. It grows linear with usage. This means having to throttle the LLM usage to stay within the margin of the flat fee and have a chance at a profit. That means using cheaper models, which yield worse result on average.
I think this is why when I compare Cursor to Claude Code I find Claude Code to be better: I’m giving Anthropic a lot more money than Cursor. But also, I’m happy with that, because I can use Claude in many other ways, where Cursor is a single-use application.
I think from now on, for each LLM powered application, I either want to be able to put my own keys in, or have pay-as-you-go with a lot of transparency. When I need it to work, I want it to work well. When I’m not using it, I want it to cost nothing.
There’s another solution though. LLM providers could have affiliate systems where other companies get a commission for the token usage they generate. Using Warp as an example, Warp wouldn’t ask me for $15/month. Warp would ask me for my Claude API key. Warp would identify all those requests as caused by Warp, and then Anthropic would pay Warp a proportional fee for the usage generated.
This is a win-win-win: Anthropic gets more token usage (more customer expansion), Warp gets more customers (I’m not paying $15/month, but I would plug in my key), and the user gets to have another LLM tool that otherwise they would not.
I’ve been thinking about this one for a while. Imagine you are the CEO of a company and your competitors are getting ahead of you because they started to use ChatGPT to build their tech. You ask the CTO what’s going on and the CTO says “ChatGPT was not on my job description, so I ignored it”. How would you feel as the CEO? Would you think “Ok, fair enough for not putting it in the job description” or would your thoughts be a bit more… colorful?
The CEO has no job description other than: “Making the company successful“. The CEO is responsible for everything. If tech fails, it is the CEO’s fault, if accounting is done wrong, it is the CEO’s fault, if marketing wastes money, it is the CEO’s fault. The buck stops there for everything.
The CTO’s role is exactly that, but just the tech part. The job description should be “Do anything and everything in the tech domain to make the company successful“. Are the servers down? It is the CTO’s fault. Marketing doesn’t have the features they need for a campaign, it is the CTO’s fault. Ransomware destroys operations, it is the CTO’s fault. Tech is spending too much money, it is the CTO’s fault. Too much technical debt, too little, not delivering fast enough, having the wrong kind of skills on the devs, devs are unhappy. Again… it all falls on the CTO’s shoulders. At least this is how I take on the role when I carry the title of CTO.
This means the CTO is responsible for problems that nobody ever assigned to them. That’s one of the reasons this role is hard. And to be able to do such a role, the CTO needs autonomy, information, access, etc.
Autonomy is achieved through budget authority. The CTO presents a budget to the CEO and CFO, who approve it and then executes on it. Ideally, then the CTO receives periodic updates from the CFO comparing expenses to budgets, and whether the company has the revenue to back that budget up. If the CTO overspends beyond the tech budget, that’s a problem, but if the company shrinks, that’s a problem too. In both cases the CTO should be proactively thinking about how to cut cost and manage the expenses (before hitting a wall, having a massive layoff, etc).
Information and access is achieved through having a strong exec team. An exec team that is all on the same page. Including a clear vision from the CEO, a clear understanding on how all other departments are achieving their goals, and how tech helps or hinders them.
So if there is a job description at all, it should be not for the role of the CTO, but rather for the company itself: what it means to achieve, and how it behaves to empower its C-Suite to further their ambitions.
To convince people to come work for you you offer them, aside from compensation, perks. And you try to have better perks than your competitors (other employers). Brainstorming with my friend Justin a few years ago I came up with what I believe is the ultimate perk and since then I’ve been desperatly trying to find a place to deploy it. I haven’t found a place where I feel even comfortable bringing it up, that’s how far I am from deploying it, so I’m sharing it with the world. If I was running my own company, I’d deploy it in an instance, not giving it a second thought.
This is the perk: every developer gets a confidentiality-bound personal assistant. There wouldn’t be one PA per developer, because they don’t need nor have enough work that can be delegated to keep one person fully occupied. Instead there would be one for all of the developers (or two, or three… or whatever you need depending on how many devs you have).
First, I don’t think this would be a very expensive perk, because actually delegating work to a PA is a skill that you have to learn and most developers will not have it. Most developers will not know where to start. But most developers will likely enjoy saying “I have a PA” or “I have a secretary”. Having said that, I would actually run courses for the developers to learn to delegate because…
It’s a perk that pays for itself. You might think you are paying for extra employees or contractors, but your developers are likely the most expensive salaries in your books. So if they can pass a task to someone else, you are saving money, not spending money. Let’s say a developer needs to arrange a call with a vendor to discuss a technical mater. They have to search for the right person, their contact details, go back and forth over emails. Imagine if the developer just tells their PA “Can you arrange that call?” over a Slack message and that’s the end of it. Back to coding!
Think about making reservations, making doctors appointments, running errands, making phone calls in general (this is why they should be confidential). Developers tend to hate phone calls. Imagine if they could delegate to someone complaining about a flight ticket that got canceled! I once had a coworker who spent half a day on hold while pretending to code.
It’s a perk that generates retention: you know why Google pays for food, haircuts, laundry, doctors on-site, etc? It’s because that generates a lot of retention. When you quit Google, you not only need a job, you also need to find a hairdresser, a place to clean your clothes and make doctor’s appointments. They treat you like children and you became as dependent as you were on your parents. I’m not exactly sure where the ethical boundary is here, but offering a free PA feels on the good side of things.
It’s unique: nobody is doing and I bet nobody will start, even after it’s been proven successful. It’s like private offices: we have the studies to prove that developers need silence to focus and yet we cram them in open office buildings. Private offices, and PAs, are for the three-piece suit executives, not for the lowly developer, so it’s not a perk likely to get devalued when everybody picks it up, because nobody will.
It’s loud. Imagine when the developer is hanging out with other developers and jokingly says
Have your people call my people to arrange it
Oh… you don’t have people? I do… this email address and phone number is my PA, just call them… and if you want a PA, come work for us.
You should not send rejection emails to job candidates when there was no interaction. For example, in the case of rejecting someone just from the application, without a screening call.
There’s a mantra that good recruiters and hiring managers take on the difficult task of sending rejection emails instead of just ghosting candidates. But I don’t think this should be a black and white decision. Do you agree? Disagree? Please leave a comment with your point of view, I’m intrigued.
When you had a screening call with the candidate, then the candidate will likely be wondering about the next step, so if the rejection happens at this or any other later stage, then yes, ghosting is extremely rude and you should always send a rejection email and possibly some feedback for the candidate to improve. More on that later.
If there hasn’t been any interaction, you shouldn’t have your only interaction with the candidate be a rejection. The reason for this is that most of us have, at some point, been desperate, and started applying to lots of jobs hoping that someone would pay us some attention, hoping we may accidentally open a door, and because being homeless is worse that shotgunning job ads. And actually, when the job ads are anonymous bland indistinguishable walls of text, there’s not a lot you can do other than hit apply and move on, so don’t hold it against the candidate.
The problem is that then this candidate might have hundreds of applications that result in tens of rejections emails. Rejections for roles the candidate forgot about 10 seconds after hitting apply (how long can you remember a non-descript job post about an anonymous company anyway?), so all you are doing by sending the rejection is reminding the candidate that they didn’t get something they forgot they tried to get. When you get tens of these, one after another, it’s emotionally debilitating. It’s no wonder that a candidate might snap at one too many rejections.
Oh, and about feedback: if you have nothing to say, don’t say anything. If you are going to give feedback, give actionable feedback. Giving someone impossible feedback is a slap in the face. For example, for a few years, I’ve been wanting to have an engineer manager position at a big scale-up or at a big company. When I get rejected and I ask for feedback, most of the time it boils down to “You haven’t been an engineer manager at a big company before”. What am I going to do with that? They might as well tell me “Have you tried being a different person? Have you tried having been born in a different country?” It’s useless and infuriating.
Originally my book was called “Building and Managing Distributed Teams“. I loved that title and people in my social circle loved it too. A friend of mine even told me something along the lines of “I’m so envious I wish I had that title”. And for the two years or so that it took me to write, abandon, restart, abandon again, restart and finally finish the book, I was happy about the title.
I had three different people ask me what I meant by “distributed”. The first time I ignored it, the third time I panicked.
As I finished writing the book and it went into proof reading phase, I thought I should try to market it a bit. I’m self publishing, doing everything, including promotion and marketing (hint: I can use your help in getting the word out). During conversations I had three different people ask me what I meant by “distributed”. The first time I ignored it, the third time I panicked.
I’ve been working from home since the early 2000s. I’ve been building remote/distributed teams and companies since 2011 or so. At the beginning we were called and we called ourselves remote workers. But that soon started to carry a stigma. Companies would have in-office workers and remote workers and remote workers were second class citizens.
This created a division between being a remote worker and working for a distributed company. The latter was much better.
The companies that wanted everybody to be remote, the companies that were remote-first, the companies were being remote didn’t mean second class citizen started calling themselves distributed. This created a division between being a remote worker and working for a distributed company. The latter was much better. The movement of distributed work was growing, Automattic, Github, and many other companies were charging ahead… and then the pandemic happened.
I don’t think the amount of people using the term “distributed” changed during the Covid pandemic, but the amount of people using the term “remote” did and might have turned “distributed” into a rounding error. The natural change of title for my book would have been from:
Building and Managing Distributed Teams
to
Building and Managing Remote Teams
I wanted to measure this, but I couldn’t find any way to do it. I tried Google Ads but I couldn’t make it work and no other method seemed to even be feasible. One of the problems I had is that I believe polls would be useless, because once you give context to “distributed”, I think everybody understands it, and it might sound better. I wanted to see how they behave in isolation. At any rate, “remote” won in polls, but not overwhelmingly.
Since I was going to change the title, I may as well consider any and all possible titles, not just a single word change, right? My friend, Justin Megawarne, came up with a very important point: the title doesn’t contain the value proposition. Think of the book “The Four Hour Work Week” by Tim Ferris. If it would have had a descriptive title, like “How to Delegate Work”, he would not have been a bestseller author.
I tried to find a value proposition name for my book and I gave up
I tried to find a value proposition title for my book. Companies struggle to hire, grow and manage in-office teams. This is a pain that exists. My friend and advisor works with many companies like that, he wants to recommend them my book, but he knows they don’t believe a book by that title has the solution to their problems. I tried to find a value proposition name for my book and I gave up.
If I remember correctly it took Tim Ferris weeks of research to come up with the title and cover of his book. I don’t have weeks to dedicate to this, in part because even with the perfect title and cover, without an editor and publisher, with just my own ability to market, it’s not going to have a positive return on investment. And thus, the new title was selected:
I did introduce some extra changes. From the conversation with Justin I switched “Building” for “Hiring”, to have the keyword of the pain point a lot of companies are going through. I also asked Ana Bibikova for her opinion since she’s both a marketer and an author. She advised me to switch from imperative phrasing to “How to”. I’m not sure what the effect will be, I don’t have a strong opinion and I trust hers.
And now, the list of explored and abandoned titles:
Building and Managing Distributed Teams (current)
Building and Managing Remote Teams
Hiring and Managing Remote Teams
Find the Best Talent Everywhere
Hire the Best and Keep Them
Stop Struggling to Hire and Managing Remote Teams
Hire Remote: Manage Remote: Stay Remote
Hire Remote, Manage Remote, Stay Remote
Doing It Better Remotely
Hire, Manage, Stay: Remote Working and What It Should Look Like
Do Better: Hiring and Managing your Remote Team
Remote Teams Done Really Badly (A How Not To)
I think some of those might come back as titles of blog posts.
I started coding when I was 7 years old and until I was 29 or so, my whole professional life was coding. Then, the startup I co-founded had to hire some people because it was doing well and I became a manager. I discovered I love managing as much as coding, but there was an ongoing issue: at the end of a day coding, I could look back at my code and feel productive, whereas at the end of a day managing, mostly meetings, I felt exhausted and with nothing to show for.
I highly recommend it to all managers: write down notes.
I’ve been managing for 10 years, taking over and building teams from scratch, being hands on and hands off and that feeling of not being productive is rarely there and I think there’s one habit that I have that helps a lot and I highly recommend it to all managers: write down notes.
I go into every meeting with some note taking tool. If the meeting is face to face, I prefer to stick to pen and paper, because a computer can stablish a divide. The other person doesn’t know what I’m typing, I may be chatting with a friend. With pen and paper it’s immediately obvious I’m taking notes and there’s no wall (the screen) between me and the other person.
But now we are all remote, and the notes are digital. This is so much better because it cuts down (but doesn’t completely remove) the need to process notes post-meeting. Depending on the type of meeting, I even share my screen so the other person can look at the notes I’m writing. You have no idea how many misunderstandings were caught this way. They said something, I misunderstood them, wrote it down in front of them and they corrected me. If you are not sharing notes, repeat what you wrote to the other person to have the same effect. This is similar to active listening.
There are a few more things that I do with my notes that I highly recommend.
I try to make all my meetings 50 minutes long, with 10 minutes to review and action notes. If we reach the 50 minute mark, ideally, I want to just book another one to continue. Having meetings overrun and everybody being late to the next meeting is very bad to the morale of a company but being the only person enforcing the strict end of meetings can be hard.
When I review the notes, if the meeting was just the two of us or sensitive, I write them down on an email and I send them to the other people in the meeting. This helps have a shared record of what happened. Otherwise I write them down on a public record in a centralized documentation system, like Confluence or Notion.
Looking at my written notes gives me the same feeling of accomplishment than looking at my written code. I’ve done something.
Once a week I go through my week worth of notes to see if I have missed something. If they are written on paper this is when I digitize them for permanent record. This also informs the report to my boss about what happened that week. Looking at my written notes gives me the same feeling of accomplishment than looking at my written code. I’ve done something.
When you are building a B2B SaaS product it’s very hard to know what the appropriate price for your product is. Even if you magically found the correct one, it might not be the correct one next month when you made the product better and you are providing new values. That’s why you need to be constant experimenting with prices on your app.
When I started my career I was afraid of raising prices, of having to justify why they went up (I wasn’t even aware of grandfathering). When I started to learn that most entrepreneurs set their prices too low, my partner and I decided to set the price too high and then lower it if it was necessary. Without realizing we painted ourselves to a corner.
We didn’t want to just lower prices, we wanted to experiment with prices (switching from per-user to 3 plans, things like that). The problem was that anything we would come would cost a different amount for each customer. For some customers it would go up, and that wasn’t a problem, because we would grandfather them in. But for some customers it would plummet.
There were two options for those customers:
Lower their prices according to the new plans and lose the revenue.
Don’t lower their prices and risk them being very angry about overpaying.
Because we were a bootstrapped startup living month to month, every time we discussed this we would get stuck in a cycle of what-ifs one or the other situation. Eventually one day we made a rule of forbidding talking about pricing (trying to get some work done, because we would spend days and days discussing pricing).
Eventually I found myself wishing that instead of starting with a high price and lowering it for experimentation, that we started with a low price and raising it for experimentation. We would have experimented much more. There’s another obvious solution which is not depend on the sweet revenue of those high prices. But even though it’s simple, I don’t think it’s easy… like sitting in front a pizza and not having a slide. Yeah… right!
Next time I want to increment prices over time and even then try to give myself room for experimentation.
I once got a job at a company that was acquiring a massive piece of intellectual property from another and it was my task to build a team to maintain and transition the knowledge as well as running assets (servers, databases, etc). The company that hired me had no relevant the documentation and the IP we were buying came with very little and all potentially obsolete. Everything was a matter of asking random people one after the other piecing together the puzzle until the answer was built. Oh… and I had 6 months to get it done.
The process of starting to write documentation was very daunting, so I created a new type of document that I named “Exploration”. An exploration is frozen in time and describes something that happened, was found, discovered, figured out, etc. For example an exploration might say: “My boss asked me to add an account, I didn’t know we had accounts. I asked Johnny and he said Sally used to do it but she left. I asked my boss who replaced Sally and I was told to talk to Sam. Sam told me how he adds accounts, the steps are 1, 2, 3, 4. He doesn’t know what step 3 does but he knows that if you don’t do it, the account doesn’t work.”
An exploration is frozen in time and describes something that happened, was found, discovered, figured out, etc.
I bet I’m not the first one to come up with this concept, but I haven’t seen it anywhere. Have you?
The goal of the explorations is to quickly form a written corpus of documentation about “How do we do things here?”. This allows you to depend less on people, which is very useful during transitions or turbulent periods where people might leave.
One of the key aspects of explorations is that they are narrative, informal, and not necessarily high quality. It’s hard to write the manual so people don’t do it. Specially if it’s a big manual of which nothing is written. The exploration is a brain dump.
Explorations should be stored in a centralized documentation system that’s easily searchable. My preference is Confluence (maybe using the blogging feature), the cool kids are using Notion these days. Stay away from Google Docs, because it promotes private copies and there’s no way of having a single tree or directory of documentation. Being able to easily search all explorations is very important and they should be searchable with the rest of the documentation.
Explorations sometimes evolve into proper documentation, procedures that are maintained and live. When that happens, I often have a See Also section in the document that points to the explorations that influenced it and at the top of the explorations I add links to the document. It’s important to note that explorations are tier 2 documentation and it’s important that everybody knows it so that they are not taken as truth when read and are written liberally.
The frequency at which explorations are created changes depending on what’s going on at the company, but generally people should be writing them any time they faced something puzzling. The way I do it is very simple: I constantly debrief with my team about what they did and after they told me the story of what happened, what they did, the workarounds and we have a good laugh, I almost always say: “Please, write an exploration about it”. It takes some effort to get started, but I think often people realize not having to remember things and just making brain dumps has a lot of value. Eventually they would just write explorations without me asking.
Don’t expect explorations to have an immediate effect. It takes time to build a corpus of data that is worth searching for answers. It might take you a year to get there.
If you are managing a team of people that are transporting rocks from A to B and you spend one hour picking ups rock from A and dropping them on B, you added one hour of work. If you spend that one hour procuring wheeled carts so that people don’t have to carry rocks on their backs, you increased their performance by 25% (and happiness). One task makes you an adder, one makes you a multiplier.
And this is very semantically correct. If your team has 0 people, increasing 25% of 0 is still 0. Your effort was wasted.
If you are a multiplier, the more people you manage, the more impact you have. That’s why often the compensation of a person at the top of a huge organization is so big (not to say that current CEO compensation is correct, that’s another story).
I find this is a good heuristic to know if I’m working on the right thing as a manager. Am I adding or am I multiplying? Sometimes I have to add, but if all I do is add, am I a manager?
The output of a manager is the output of the organizational units under his or her supervision or influence.
Andy Grove, High Output Management
Something to keep in mind is that multiplying is hard. Well, it’s hard to find the opportunities when you can multiply. You need to sit down, look at the team carrying the stones, think about a better way, go find some carts, get a quote, evaluate it, run an experiment, see the increase in performance, discover not everyone knows what to do with it, write the manual and the training program, stop everyone from carrying stones (temporarily dropping productivity) so they can learn to use the wheeled carts.
If as a manager you are so busy with interruption work that constantly lands on your lap, busy doing adding work, you will not have the time and mental space to think and find opportunities to multiply. This is why I don’t like the always-busy CEO or always-busy manager. When do they do their thinking?
