Just looked at my last blog post and saw the date was Apr 9, 2010. That’s almost 9 quarters. Since I last blogged, here are some of the things I’ve done and learned about myself:
- Shut down my first startup
- Got a job at LinkedIn in the mobile team
- Helped rewrite LinkedIn’s mobile server from the ground up in node.js
- Learned Clojure (and love it)
- Went from SW Eng to Eng Manager (again)
- Got a ton of experience running (and troubleshooting) servers at internet scale
- Learned that internet companies go much, much faster than other types of software companies
- Learned that some of management advice I’ve been giving in Management Revolution doesn’t apply when companies move really fast
- Found that under stress, I get angry (you wouldn’t like me when I’m angry)
- Found that I really like writing software and I really like being in a leadership role
- Found that I seem to have a knack for winding up in leadership roles even when I don’t seek them out (or even want them at times)
- Found that I like the role of “ronin warrior” than samurai
- Found that if I drink too much tea and not enough coffee, I get too mellow
- Found that after two years, there’s still not a good tool for managing groups of people across multiple projects
- Selling to enterprise customers sucks
- Getting individuals to try a product is much easier than getting a group to try a product
- It’s impossible to convince someone to change how they work
- I love my iPhone thousands of times more than my Android.
- I want to try starting another company
I’ve been using the Pomodoro Technique for the past few months and have found it extremely effective for helping me focus.
What you do is set a timer for 25 minutes and focus on doing one and only one task during that time. You keep working on it until you’re done. You don’t get up to make some tea. You don’t check your email. You don’t go to the bathroom. You just sit in your chair and force yourself to work.
The first couple of times you get very anxious. After a while it gets fun. You’ll be amazed at how much you can do this way.
One caveat: I’ve found that 25 minutes is too short when I’m debugging. I get very irritated when the timer goes off and I’m in the middle of troubleshooting. On the other hand, you do need something to keep you from chasing a bug fruitlessly for the next 4 hours. The best solution is to use a longer time period and force yourself to stop and take a break. 50 minutes is a good duration for this (at least for me).
BTW: The game I like to play is when I hear my email client announce a new email, I ignore it — I win; the distraction loses. I know it’s not much of a game, but at least I always win 🙂
P.S. The timer I use is Minuteur.
Whenever I first meet an entrepreneur, they seem full of confidence and optimism. After I introduce myself as a fellow entrpreneur, the ridiculousness of that pretense falls away.
All entrepreneurs are unsure of what will happen next. We’re on this rollercoaster filled with anxiety. We take things personally, but we try not to show it. We believe in what we’re doing, but missteps give us pause. We’re an odd mix of possibility and uncertainty, conviction and doubt –never sure if we’re being persistent or just plain stubborn.
Only time will tell if we’re right. I think the trick is lasting long enough to see if we are 🙂
I went on a sales call last week for our product Lakeway Frontier and was reminded of something that one of our first users pointed out to me: Frontier supports a methodology for how you manage engineering teams — but you have to adopt the methodology first.
I was kinda hoping the value of the methodology would be self-evident 🙂
I’ve come to this way of managing teams after a decade of observation on how engineering teams function: what happens when they run great, and what happens when they go wrong. I’ve been fortunate to have had several teams of my own on which to test out ideas on how to better manage organizations. Lakeway Frontier is a product that captures what I’ve learned and automates away the most tedious, onerous work involved in managing projects and teams.
I guess I’ve been thinking about these things for so long, that they’ve become second nature to me. I forget that for most people, these ideas represent a paradigm shift in engineering management, albeit one that has tremendous potential for improving execution, accelerating decision-making, and reducing workplace stress. Since, in effect, what I’ve been trying to do to this point is lead a management revolution, let’s just call it that.
I’ve started a blog called “Management Revolution” that will have daily posts on what needs to change in order for organizations to run better, especially engineering groups. I hope you find it useful.
For some time, I’ve been working every day whenever I had the chance. Today, I decided that I wouldn’t work at all (well, I did work for 25 minutes this morning, but I committed to not working after that :-)).
The last time I had to take a break like this was the last time I had to go through this particular module in my app’s code. It’s the heart of our application and our differentiating technology–and every time I have to go back in, it makes my head hurt.
I’ve always had mixed feelings about this code. On the one hand, as I look through it, I’m reminded of how difficult it would be for someone to copy what we’ve done. It’s a deceptively simple problem that has gone unsolved until now. On the other hand, I’m disappointed in how difficult it’s been to code this up so it can be easily understood. I begin to suspect that this is one of those things that can’t be made simple.
In any case, I’ve decided to spend today without my laptop (I’m typing this up on my phone) and without looking at any code. I’m going to finish up this post, read some articles, and then head off early to bed.
Tomorrow, I’ll head into the code again. Hopefully, this will be the last time I have to do any significant coding here–after all, I still need to figure out how to sell this thing.
Maybe in my next post I’ll talk about my attempts at setting up meetings, getting product feedback, and getting people to give our product a try. If there’s anything you’re particularly interested in hearing about, feel free to leave a comment!
I’ve never liked the phrase “Trust but Verify” (especially in organizations). To me trust means you firmly believe in someone’s integrity and their ability to do something. It means when they say something will be done, you, personally, know it will be done. No need to check. It’s money in the bank.
When you feel you have to verify someone’s work, you’re essentially saying “I’m not sure if you’re gonna do this right”. When you feel you have to look over someone’s shoulder to make sure the work is ok, you can’t really say that you trust them.
Some people may think what I mean by “trust” is “faith”. While close, these are not the same. Faith is like trust except you believe without proof. Trust is something that builds up over time. Trust develops when you’ve seen evidence of someone’s performance and abilities, repeatedly, in many different situations. Trust takes time— it’s a key part of a strong relationship.
When someone says “trust but verify”, I take it to mean they don’t really trust someone’s ability yet, but they’re in the process of observing how someone works and what they’re able to do so that they can get to a state where they can trust this person.
On the other hand…
A less charitable take on “trust but verify” is that someone is pretending to trust, and hoping that people will believe them, when in fact, they don’t really trust people at all. I believe there are people who are unable to trust others in the workplace. These are the micromanagers, or worse: highly political people with closely-held personal agendas. Because they are unable trust others, they can never develop mutual trust with their reports or their managers. While they may reach positions of power and be able to flex and distort organizations, their ultimate impact and potential will always be limited. They may be skilled and successful within an organization, but they will never be truly great contributors or leaders.
In any case…
Whenever you hear someone say “trust but verify”, watch out! Trust me 🙂
What do you get if you start with “Enter the Dragon“, add some Jack Handey, throw in a couple of “Cal Pocket/hash browns”, move it to South Street, steep it in Portland, and then fold in some Gen X? Why, that’s a recipe for “Rino’s Reflections”!
Interestingly enough, if you take a look at the Jack Handey site, you’ll see that the header image I choose for this blog is remarkably (and coincidentally) similar to what they picked for theirs. I hope my posts don’t end up looking like they’re making fun of me. Out of curiosity, I went to the Jack Handey site and clicked on a random quote generator and got this:
It’s easy to sit there and say you’d like to have more money.
And I guess that’s what I like about it. It’s easy.
Just sitting there, rocking back and forth, wanting that money.