[Note from Daniel: This guest post, from my friend Steve Tolman, is part of an occasional series about important career role models. I also worked with Steve Jackson, and I agree with Tolman that his energy and dedication instilled many great skills in those who worked on his teams.]
While I worked at PowerQuest, and Symantec after its acquisition of PowerQuest, I worked with a man named Steve Jackson. He started somewhere around 1999 or 2000. In our organization we had about seven or 8 Steves so we all went by our last names. I was simply, “Tolman” and he was “Jackson.”
Jackson was the director and VP of all software engineering. He was my manager and quickly became my friend. He took his job very seriously and I learned a great deal from him.
By the time I left the team in 2008, I had learned how to run a team, how to build and release software, and how to work well with people. One of my peers, Lane Johnson (one of the best managers I have ever known, who left the team at the same time) asked me what it was that made Jackson so dang good. We thought about it for a while and concluded that there was not that proverbial one-thing-you-need-to-know that made him great, but more along the lines of about a bazillion qualities. A little time brainstorming gave us a list of 45 different skills, techniques, or approaches. Here are just a few of the highlights.
Believe in the individual
Jackson’s default mode was to trust people. Trust them to fit into the team and trust them to do their job, but expect them to do a stand-up job for you. Get the right people on the bus (read the book Good to Great for more info), give them an assignment, then get the heck out of their way and let them shine. Continue reading
If you’ve read Call it Courage, then you know the story of Mafatu, the boy who was afraid.
Mafatu grows up in Polynesia, surrounded by the ocean—but everything about the sea terrifies him, because he remembers his mother drowning when he was young. Determined to conquer his fear or die trying, Mafatu sets out alone in a dugout canoe, into the element that terrifies him most. He ends up stranded on an island that harbors cannibals. In one memorable scene, his faithful companion dog is endangered by a tiger shark; Mafatu jumps in the water and attacks with only a knife. When he kills the shark, he realizes that something fundamental in his heart is now different.
He still feels fear, but it no longer overpowers him.
He is free.
I’ve been blogging about the skills and mindset of effective software architects for quite a while now, but I recently realized that I’ve omitted the fundamental subject of courage.
image credit: nalsa (Flickr)
This is an important gap, because courage counts. The cleverest, most skilled architect or engineer will accomplish very little, at key junctures in a career, without it.
Symptoms of fear
In the past two decades, I’ve heard many people (myself included) make statements like the following: Continue reading
In the world of cloud computing, “risk” is a big buzz word. Lots of analysts are debating how much risk is involved in using SaaS offerings like Salesforce, or hosting corporate applications with a public IaaS provider like Amazon’s EC2. They’re worried about outages (Amazon’s had several ugly ones, most recently for 49 minutes in January), about security, about regulatory compliance, and so forth.
Werner Vogels, Amazon CTO, NextWeb 2008: “Everything fails, all the time.”
These worries are well founded. However, I pointed out today on Adaptive Computing’s blog that the question “Can I take the risk to use the cloud?” is a bit naive. Sometimes you can just avoid risk altogether. In many cases, however, risk is endemic, and the smart course is to manage it.
How does risk figure in your architectural vision? You should think about it all the time. You should count it, weigh and balance alternative outcomes in ways that would impress even the gaming industry.
Here are 6 key questions to kick-start your pondering:
- Is my architecture properly accounting for risk of environmental problems such as DDOS, routing failures, brownouts, and temporary loss of an internal component? (See my article about circuit breakers.)
- When one of my components crashes, will its state be cleanly recoverable (e.g., on transaction boundaries) rather than corrupt? What data loss contract am I targeting?
- Will it be easy for users or admins to notice when theoretical risks I’ve planned for become true emergencies? How will they be notified?
- Is it possible to put the system in a “scabbed” state that’s degraded and safe, but functional, while more extensive repairs take place?
- Am I assuming success too often? (Werner Vogels, Amazon’s CTO, is fond of saying “everything fails, all the time.” That’s on my top 5 list of major insights to remember.)
- Am I diversifying intelligently, and enabling my customers to do so as well?
Make a list of a handful of important risks from your customer’s perspective. How many of them can you help with?
Just read an insightful post from Seth Godin. If you don’t already know who Seth is, and follow him, I suggest you get to know him a bit. He’s a thought leader in the field of permission marketing–the founder of the movement, perhaps. He’s spoken at TED conferences numerous times. Every one of his books that I’ve read is worthy of pondering.
Although Godin isn’t speaking specifically about software craftsmen, I see direct application of his thinking to our field. Since so much of what we do requires buy-in, coordination and shared mental models, we have to be savvy about how we communicate, advocate, and train. Assuming equal technical competence, the difference between effective and ineffective technical leaders largely depends on the mastery of this skill.
Have you considered how to grow your influence? Do you have a plan?
Influence doesn’t always work the way we expect. :-) Image credit: xkcd
(A post in my “Role Models” series.)
When I worked at Perfect Search, we had a standing joke that after the meeting agenda was done and we had given the word to adjourn, it was time to turn to Lynn and get his feedback. This joke was funny because on many occasions we’d seen Lynn ask penetrating questions after the rest of us rushed headlong through an issue and assumed all the thinking was done.
Although Lynn tolerates this joke with good grace, I think the joke isn’t really fair to him, because there’s nothing funny about thoughtful listening. The world could do with more people who’ve mastered Lynn’s skill.
Listen to understand, not to respond. Photo credit: Prisoner 5413 (Flickr)
I recently blogged about the importance of humility. It is not an accident that humility Continue reading