Craft and publish engaging content in an app built for creators.
NEW
Publish anywhere
Post on LinkedIn & Mastodon too. More platforms coming soon.
Make it punchier 👊
Typefully
@typefully
We're launching a Command Bar today with great commands and features.
AI ideas and rewrites
Get suggestions, tweet ideas, and rewrites powered by AI.
Turn your tweets & threads into a social blog
Give your content new life with our beautiful, sharable pages. Make it go viral on other platforms too.
+14
Followers
Powerful analytics to grow faster
Easily track your engagement analytics to improve your content and grow faster.
Build in public
Share a recent learning with your followers.
Create engagement
Pose a thought-provoking question.
Never run out of ideas
Get prompts and ideas whenever you write - with examples of popular tweets.
@aaditsh
I think this thread hook could be improved.
@frankdilo
On it 🔥
Share drafts & leave comments
Write with your teammates and get feedback with comments.
NEW
Easlo
@heyeaslo
Reply with "Notion" to get early access to my new template.
Jaga
@kandros5591
Notion 🙏
DM Sent
Create giveaways with Auto-DMs
Send DMs automatically based on engagement with your tweets.
And much more:
Auto-Split Text in Posts
Thread Finisher
Tweet Numbering
Pin Drafts
Connect Multiple Accounts
Automatic Backups
Dark Mode
Keyboard Shortcuts
Creators love Typefully
150,000+ creators and teams chose Typefully to curate their Twitter presence.
Marc Köhlbrugge@marckohlbrugge
Tweeting more with @typefully these days.
🙈 Distraction-free
✍️ Write-only Twitter
🧵 Effortless threads
📈 Actionable metrics
I recommend giving it a shot.
Jurre Houtkamp@jurrehoutkamp
Typefully is fantastic and way too cheap for what you get.
We’ve tried many alternatives at @framer but nothing beats it. If you’re still tweeting from Twitter you’re wasting time.
DHH@dhh
This is my new go-to writing environment for Twitter threads.
They've built something wonderfully simple and distraction free with Typefully 😍
Santiago@svpino
For 24 months, I tried almost a dozen Twitter scheduling tools.
Then I found @typefully, and I've been using it for seven months straight.
When it comes down to the experience of scheduling and long-form content writing, Typefully is in a league of its own.
Luca Rossi ꩜@lucaronin
After trying literally all the major Twitter scheduling tools, I settled with @typefully.
Killer feature to me is the native image editor — unique and super useful 🙏
Visual Theory@visualtheory_
Really impressed by the way @typefully has simplified my Twitter writing + scheduling/publishing experience.
Beautiful user experience.
0 friction.
Simplicity is the ultimate sophistication.
Queue your content in seconds
Write, schedule and boost your tweets - with no need for extra apps.
Schedule with one click
Queue your post with a single click - or pick a time manually.
Pick the perfect time
Time each post to perfection with Typefully's performance analytics.
Boost your content
Retweet and plug your posts for automated engagement.
Start creating a content queue.
Write once, publish everywhere
We natively support multiple platforms, so that you can expand your reach easily.
Check the analytics that matter
Build your audience with insights that make sense.
Writing prompts & personalized post ideas
Break through writer's block with great ideas and suggestions.
Never run out of ideas
Enjoy daily prompts and ideas to inspire your writing.
Use AI for personalized suggestions
Get inspiration from ideas based on your own past tweets.
Flick through topics
Or skim through curated collections of trending tweets for each topic.
Write, edit, and track tweets together
Write and publish with your teammates and friends.
Share your drafts
Brainstorm and bounce ideas with your teammates.
NEW
@aaditsh
I think this thread hook could be improved.
@frankdilo
On it 🔥
Add comments
Get feedback from coworkers before you hit publish.
Read, Write, Publish
Read, WriteRead
Control user access
Decide who can view, edit, or publish your drafts.
Tech Lead Journal Podcast interview with @laffra & Google's Project Tempo.
youtu.be/plExAcsjIXs?t=799
My Three Favorite Passages:
1️⃣ The Importance of Communication
2️⃣ The Controversial Rule about becoming a Senior Engineer:
3️⃣ What Do the Most Impactful Engineers do?
🧵 🧵🧵
1️⃣ The Importance of Communication for Engineers [00:13:18]
Henry Suryawirawan: [00:13:18] I like the way that you said that we should probably think about reversing the hard and the soft. I kind of resonate (with) that as well. Having been an engineer all my life, as well, sometimes yes, communicating is hard.
Which brings us to the important topic here. Why do you think communication is so important for engineers? All engineers would think that, okay, my job is to write code, and I talk to the machine. I don’t talk to people.
So why do you think communication is so important for engineers?
Chris Laffra: [00:13:44] Yep. It’s a very good question. I used to work at Google, like we said in the introduction. I was involved in a project called Tempo, where we wanted to figure out how to make engineers more productive.
Tempo is actually a tool that instruments your desktop, and it just watches what you’re doing all the time. Using machine learning, we then tried to figure out how productive you were, and we tried to correlate that to whether you were happy or not.
So we actually asked literally the question, randomly the pop-up shows up, “How happy are you right now?” We just asked the question, and you gotta star it one to five, right?
If you have enough data, at some point, you can start correlating using machine learning, which is great for this. You can start correlating situations that make engineers unhappy versus situations that make them happy.
One of the things that we figured out was that deep work, like long blocks of uninterrupted, studying time on the problem and solving it is what makes engineers happy. I mean, they voted more happy when they were in this zone phase or in the concentration phase.
We also tried cameras.
So if you’re allowed, and if you’re an engineer at Google doing this research that Google does, you’re more tempting to do this by turning on your camera all day, and you can do analysis of facial expressions, and you could actually see if somebody is happy or not.
So then you have a fine-grain signal to see what are they doing right now. Like how many times did they switch between tools. And we started finding out that context switching is very expensive and they hurt your productivity.
So these are all like useful information, tried to solve a problem, like what makes them more productive.
But a side effect from that was that we also measured what are you doing right now, and classify the things that you were doing.
Like sometimes you go to email and then you spend some time there, you go to chat, and then you go to your IDE, type some things, and then you do builds.
And then if you do a measurement of how much time do you actually spend coding, it’s about 30% of your time for the average engineer that had this tool turned on. So what do you do in the rest of the time? The other 70%? And that’s all communication.
That is all interacting with other engineers. This is all has to do with making decisions together, planning, synchronizing our work, increasing the quality of the code that we deliver as a team, as an organization.
It’s about learning what is important for our organization right now. So a lot of that has nothing to do with coding, but more about why are we building the code. Or how are we doing this certain process?
So that is one interesting fact, I think. 30% of your time is coding, and you better be good at the other 70%. Because if you get twice as good in the communication part, you have a lot more opportunity for growing your impact.
What I’ve seen too is that at some point engineers become more senior. And when you get more senior, you tend to spend time in coding even less, and you spend more time into mentoring other engineers, and guiding them in trying to understand the bigger picture.
As a junior engineer, you’re right out of school. You go to standup, and they give you five tickets. And you work these five tickets and that’s it. You may have some questions about what does this mean? What does this mean? How do I do that?
But you don’t try to understand why are we building these tickets. Your emphasis is to fix these five tickets as quickly as possible and get to the next five. So at some point, somebody has to give you these tickets, and that’s what senior engineers do.
We’re all on the scale of between like junior and very advanced. But at some point, you reach a position where most of your impact is actually measured on how you influence other people. How you show leadership.
Like the word leadership in itself, assumes that you transfer your experience to other people. And that by delegating the work that you would normally do yourself to others, you can actually become much more impactful. And that requires a lot of communication too.
So when you see people transition from a more junior role to a more senior role, they will also become better communicators. So in summary, if you want to grow, you need to communicate. If you want to be productive, you want to be impactful, you need to communicate.
2️⃣ The controversial rule of becoming a Senior Engineer: The higher you go the less time you spend coding and the more time you spend communicating (planning, coordination, mentoring…) [00:18:01]
Henry Suryawirawan: [00:18:01] So I see this, as you explained, when you said that 30% coding time and 70% is more about communication, planning, coordination, and all that. And as you get more senior, the lesser time it is to actually spend time in coding.
I think this is also a lot of time, a lot of seniors, growing, aspiring senior engineers struggle as well, because they thought that when they become engineer, they are supposed to do a lot more coding work. But as they progress throughout their career, the reverse is true.
The less time you spend in coding and more about communication. What’s your take on all this?
Chris Laffra: [00:18:35] Yeah, of course there are exceptions. There are always individuals that if you look at the knowledge over experience of a particular individual, there is something like the T experience, a T structure, right?
So you’re broad, but then you have one specialist in which you’re really deep. Most engineers, if you ask them like, “Hi, I’m Chris and who are you?” And they said, “I’m an Android engineer.” Or they say, “I’m a backend engineer”, or “I write Go”, or whatever.
This is not you, right? This is one of your deep skills. So as a senior engineer, you start to focus more on your horizontal skills. Like your understanding of the full stack of the problems that customers have and how are we solving them.
Being able to break down problems into smaller parts, communicating teams, like I said earlier, seeing the bigger picture. So those skills come up automatically once you get more senior.
There are many channels in which you do this communication. I’ll just give you some examples here. It’s like emails, tickets, chats, design docs, meetings. And a meeting is multidimensional. You have to learn how to send invites.
That seems like a simple thing, but it’s not so simple. Somebody has to take notes in the meeting. How do you set up Zoom? How do you set up a camera correctly? Who is talking in the meeting? Who is making sure that everybody’s heard? How do you get diversity?
But some actually excel, and they treat this as an opportunity to sell their brand. That’s what you see as well as like successful engineers. They have a brand and they treat it as such. I mentioned earlier, performance reviews, which are highly stressful event for engineers.
Because now you suddenly you have to write about what you’ve done this year. Even if you remember, how do you actually translate it into something that other people find impressive? It’s not easy. Even writing commits, code reviews, these are all communication.
Henry Suryawirawan: [00:18:01] So I see this, as you explained, when you said that 30% coding time and 70% is more about communication, planning, coordination, and all that. And as you get more senior, the lesser time it is to actually spend time in coding.
I think this is also a lot of time, a lot of seniors, growing, aspiring senior engineers struggle as well, because they thought that when they become engineer, they are supposed to do a lot more coding work. But as they progress throughout their career, the reverse is true.
The less time you spend in coding and more about communication. What’s your take on all this?
Chris Laffra: [00:18:35] Yeah, of course there are exceptions. There are always individuals that if you look at the knowledge over experience of a particular individual, there is something like the T experience, a T structure, right?
So you’re broad, but then you have one specialist in which you’re really deep. Most engineers, if you ask them like, “Hi, I’m Chris and who are you?” And they said, “I’m an Android engineer.” Or they say, “I’m a backend engineer”, or “I write Go”, or whatever.
This is not you, right? This is one of your deep skills. So as a senior engineer, you start to focus more on your horizontal skills. Like your understanding of the full stack of the problems that customers have and how are we solving them.
Being able to break down problems into smaller parts, communicating teams, like I said earlier, seeing the bigger picture. So those skills come up automatically once you get more senior.
There are many channels in which you do this communication. I’ll just give you some examples here. It’s like emails, tickets, chats, design docs, meetings. And a meeting is multidimensional. You have to learn how to send invites.
That seems like a simple thing, but it’s not so simple. Somebody has to take notes in the meeting. How do you set up Zoom? How do you set up a camera correctly? Who is talking in the meeting? Who is making sure that everybody’s heard? How do you get diversity?
But some actually excel, and they treat this as an opportunity to sell their brand. That’s what you see as well as like successful engineers. They have a brand and they treat it as such. I mentioned earlier, performance reviews, which are highly stressful event for engineers.
Because now you suddenly you have to write about what you’ve done this year. Even if you remember, how do you actually translate it into something that other people find impressive? It’s not easy. Even writing commits, code reviews, these are all communication.
3️⃣ How to Become More Impactful Engineers [00:30:58]
OR
What Do the Most Impactful Engineers do daily?
Henry Suryawirawan: [00:30:58] So you have also another thing, while we we were speaking about this. There seem to be some engineers who are actually good at selling themselves, so to speak, like good communication skills.
So what do you think those things that make these type of engineers actually more impactful than the others?
Chris Laffra: [00:31:13] Yeah, what I mentioned, the research done at Google for getting more insight into what makes an engineer productive. They also did research into understanding what makes certain people more productive than others or more impactful.
So what is a highly successful individual at Google? What are the attributes?
And if you analyze their communication network, you can actually do at Google because you have access to all the metadata there, anonymized and all, but you can actually understand how they interact with other people through all these channels that I mentioned earlier.
There are breadcrumbs for each interaction, every email, every meeting, every chat. And then if you put that all in one big graph, and then you look at this individual, this successful person, they look like what is called a super node.
They’re the one in the middle and everything connects to them. You can see sort of islands, there’s a little team in the top right. This is like five or six people that work on a certain tool. And then in the bottom left, there’s another team.
And they don’t connect with each other, but they connect through this person.
So you can see this is the typical design interview that you do, when you go with a tech company, they say like, build me Twitter. You start drawing boxes and they say, “Well, isn’t this a bottleneck?” So in design interviews, these bottlenecks are a no-no.
You want to avoid them in your design of your software. But in real life, these bottlenecks, if they are people, they are actually the most successful ones, because they monopolise this information. So that’s one observation.
So just by communicating a lot, by having a big network, and I mean that literally, not the social network kind of network.
If you have a big network of interaction, your graph is big, the chances are that information flows through you is higher, and that you control the destiny of individual teams. Let’s just put this very dramatically here.
But you can filter information and share it with others to make it very effective. Very successful people know how to do this intuitively, but they learn. This is a skill, again. So you have to figure out, you have to develop empathy.
You have to understand who you’re talking to. Like we do with networks, you have a protocol and you get in a JSON record and you have to transform it to protobuf.
You filter out certain things, you extract other things, you get some other information from a third source, and you enrich the data, and then you generate a new packet. This is what successful communicators do as well. So this is not a metaphor from our common background here.
What I’ve seen too is very successful people, they treat other people like an audience. And I don’t mean that like they’re an influencer on YouTube or something. But what I mean with that is they aim to influence other people in a profound way.
So rather than just educating them, this is what our product can do, and here are all the features, whatever. They try to inspire other people to use the product. Instead of motivating them to do something, they fire them up.
These are like different levels of engagement that you try to create with your audience. And instead of influencing, which is that’s what we think, if you’re a leader you’re influencing others. No, no, no. Your goal has to be to change lives.
How do you actually make people feel better just by being there, and how do you do that? So there are some tips tricks you can use. Like how do I get to that stage? How do you build charisma? How do I make people like me?
Like when I go to a party, I just want to sit on the edge. The word wallflower is invented for this. Most engineers are wallflowers. They don’t want to stand in the middle because then you get, “uh, I’m uncomfortable there.”
But if you do communicate, I develop five rules that you can apply that I’ve seen a lot of successful engineers use. So the first one is facts. Your communication should be based on facts, not on feelings, not on assumptions.
If you meet your director, and you have this great idea to use a new database, or some new API. You go to the director and you say, “I think we should use this.” And he says like, “Why?” And now you have to explain why, right? “So, our transaction rate will go up by 200%.
Now this is a great thing because it will lower our costs and blah, blah, blah.” “Oh yeah. Those are great facts.” So now your decision-making is based on knowledge, not on feelings. So try and sprinkle in your facts in your decision-making. So don’t say, “I think”.
But say, “because of these numbers, we should do this.”
So that takes me to the second point, which is conviction. So never come over as somebody who doesn’t know, but use the facts that you obtained in your previous phase, and use them to change your language. Just your posture, the way you communicate with other people.
And you’re the expert. Just assume that, and how do you know? Because you researched it, right? You looked at all the alternatives, and this is the best alternative. And therefore we do this, just sign here. This is how you structure a design document as well.
So if you write a design document that explains to the rest of the organization, why we should build something? You have to tell them, and they have to sign off on this and approve it. What technologies will go into the system? And what alternatives are there?
And why have we chosen for this one? So sometimes this is build versus buy. There’s an open source technology that almost does what we want, but of course it will not work for our environment, so we have to build ourselves.
Or there’s an internal system that, like I said earlier, only has JSON, we need protobufs so we can use it. So there’re some technical reasons why you will discard one alternative and choose for the other.
But you have to be showing conviction, and you can only do this if you’ve actually looked at the alternatives and you know which one to choose. So make sure that you become an expert and then radiate that expertise to others.
That doesn’t mean you have to become arrogant. “I know everything is right, so we have to do this.” But you translate your conviction to others by giving them the reasoning behind this.
And that takes us to transparency. So transparency is about showing other people what your decision-making matrix looks like. As engineers, we tend to be uncertain in this. But it’s not easy showing yourself to be the expert because, “Oh, man.
I don’t know, these other people are way smarter than me. I want to make the document perfect before I share it.” That’s what a lot of engineers told me. Like, when I said, “Why haven’t you shared a document yet?
You’re working on this two, three weeks now.” “Yeah, it isn’t done yet.” No. This is not how we develop software. We have an agile approach, right? We have a running system and we incrementally make it better. So treat your documents in the same way.
Make your documents transparent and invite criticism as soon as you can. So ask other people to give their feedback on one of the decisions that you have there. If it’s like on a data storage topic, you reach out to an individual who has the expertise on that.
And you say, like, “Am I making the right decision here?” If it’s about observability aspects, you add an SRE and you say like, “I’m planning to use this and this technology to get a daily dashboard, will that work?”
So you very quickly open up your analysis and you are discovering things to others.
You will discover that collaboration there becomes much more effective.
And this comes back to performance and promo again. Like one of the things that we do in promo projects is we look at all your diffs, of course, but especially as a senior engineer, you’re expected to have written some design docs that describe your contribution.
How do you get started with this as a junior engineer? What we’ve seen often is that engineers think that to get promoted, you have to write the design doc. Like it has to be your work. But that’s not how it works, really.
What the committee is looking for is your ability to communicate, your ability to collaborate, to engage other people in the decision-making, and to find mistakes quickly. Because if you find mistakes late, they’re extremely expensive to fix. We know this in software.
If a bug comes in from a customer, this is really expensive. So this is why we do testing, right? We don’t do this enough with documents. So if you write a design document, aim for collaboration. Work with other people.
Don’t just put your own name on top, put five people on top. Because if you now have four other people writing this doc, you only have to spend 20% at it, and then you can spend the other 80% on four more docs.
And now you go to promo time and suddenly you have five documents that your name is on top. So this allows you to not just learn how other people work, you grow your network, it is actually an indicator of you’re being more senior, and you’re not fighting with other engineers.
You’re not trying to win this game of getting recognition, but you aim for making the system better.
So consistency is then the fourth area. So we talked about facts, conviction, transparency. Consistency is all about keeping your message simple. Because if you make it simple, then it’s a lot easier to say it right the second time.
This comes back in like we said in promo documents, but also in design documents and emails, even in chats. And then the fifth direction if you want to be a successful communicator, as an engineer, is to show people a positive direction.
That’s not easy, but we often focus on the problems as engineers, right? All the possible ways that this can go wrong. If you look at somebody who is like a product manager, and they talk to customers, they have a much more positive look on life.
They know how to articulate goals into something that is a better place. So as engineers, we should also focus on that because people are really inspired if you tell them something positive.
If you just tell them the negative things, if you’re in meetings and you’re always explaining why that won’t work, at some point, people will start hating you. It’s not because they hate you, but they want to hear something nice and that’s something positive.
So if you focus on that first, be optimistic. I’ve always been very optimistic in my career, in my life. Problems are there. Like I always say, “A problem is an opportunity.” A problem for one is an opportunity for another.
If you look at the problems, then this is an opportunity for you to show how your impact will actually turn this problem into something positive. So keep that mindset in place.
So facts, conviction, transparency, consistency, and a positive outlook on life will make engineers much better communicators.