Last post I wrote about my decision to leave JPL. Now about where I'm going...
Aw, c'mon, you had to know I had something in the works. This move is more about running to something exciting than it is about running away from anything.
I was fortunate enough to have several opportunities to choose from. Money wasn't really much of a factor (once you cover food and shelter, anything else is gravy anyway). Yeah, I got a little more...but I also passed on a lot more. This was more about doing work that excites me with people who share that passion.
One opportunity stood out: cutting edge work that I care about, the chance to work with people I like and respect, and a company that went the extra mile to let me know that they wanted me in particular.
I still have to pass a drug test (no worries - steroids don't improve your apps skills, so there's no point) and a background check (that could be tricky if they go back to my college days) but, assuming that goes well, I'll be joining the team at Innowave Technology. Really looking forward to working Basheer and the group at Innowave! Working together, we're going to make some dents in the universe.
So this is what it's like to really manage your career. Somebody tell LeBron I've got some cool new lessons to share!
Thanks again to the good folks at Talented Apps for inspiring me, and for all the people who have supported me in this. I'm a lucky boy.
We now return you to your regular programming.
- Posted using BlogPress from my iPad
Wednesday, May 26, 2010
Tuesday, May 25, 2010
Moving In A Different Direction
"After a long and deep analysis of all of the factors that led to the disappointing early ends to our playoff runs over the past two seasons, we concluded that it was time… to move in a different direction. "… expectations …are very high and, although change always carries an element of risk, there are times when that risk must be taken in an attempt to break through to new, higher levels of accomplishment. This is one of those times."
The quote above is taken from Cleveland Cavaliers owner Dan Gilbert's words on firing coach Mike Brown earlier today - it's heavily edited by me to fit my purposes here. Although I do think Mike Brown got a bum deal here, that's another story. I like the words in context of what I've done with my own career today. I submitted my notice of resignation at JPL.
Why? Three reasons:
1) I'd done what I came to JPL to do.
- Improved JPL's functional knowledge of the E-Business Suite.
- Helped improve JPL's relationship with Oracle.
- Established a project management methodology and a PMO.
All three long-term goals checked off…I've taken them all as far as I can.
2) I'd become very complacent and more than a little bored. I was slipping, my skill set was fading, and it was obvious I needed some new challenges to get my Mojo back.
3) The direction my shop is taking, in terms of more process control over IT projects, is directly opposite of the direction my own thinking is going (too much process control kills productivity).
I got a great deal of inspiration from the good folks over at Talented Apps, especially in terms of taking responsibility for my own career. So that's what I'm doing…we'll see how it goes. And, yes, I do have someplace I'm joining…but that's another blog post.
The quote above is taken from Cleveland Cavaliers owner Dan Gilbert's words on firing coach Mike Brown earlier today - it's heavily edited by me to fit my purposes here. Although I do think Mike Brown got a bum deal here, that's another story. I like the words in context of what I've done with my own career today. I submitted my notice of resignation at JPL.
Why? Three reasons:
1) I'd done what I came to JPL to do.
- Improved JPL's functional knowledge of the E-Business Suite.
- Helped improve JPL's relationship with Oracle.
- Established a project management methodology and a PMO.
All three long-term goals checked off…I've taken them all as far as I can.
2) I'd become very complacent and more than a little bored. I was slipping, my skill set was fading, and it was obvious I needed some new challenges to get my Mojo back.
3) The direction my shop is taking, in terms of more process control over IT projects, is directly opposite of the direction my own thinking is going (too much process control kills productivity).
I got a great deal of inspiration from the good folks over at Talented Apps, especially in terms of taking responsibility for my own career. So that's what I'm doing…we'll see how it goes. And, yes, I do have someplace I'm joining…but that's another blog post.
Monday, May 24, 2010
Just Do It
I've recently discovered 37Signals and have become a big fan. Like their apps and the way they think. I've really enjoyed their recent book Rework and their earlier book on web apps development, Getting Real. The latter book in particular really struck home with me, especially the technique recommended for building web apps:
1. Learn about the job that needs to be done (which is very different from just gathering requirements).
2. Stick to including only essential features
3. Put up a UI prototype based on what you know.
4. Gather feedback on your prototype.
5. Revise your prototype for the feedback you receive.
6. Repeat steps 3 and 4 until you get something worth putting up in production.
7. Build the necessary back-end coding.
8. Put your app up in production
If your app needs more after the first production release, rinse-wash-repeat.
The upshot here is to get up and do something...just do it. The book also suggests that this technique applies to much more than web apps and, after some consideration, I agree.
Last week, I had the good fortune to attend an OTN Architecture Day focused on SOA. The major concerns I heard repeated by others in attendance: it's darn near impossible to make a strong business case for SOA. And they're right. When you just consider Oracle's flavor of SOA, the breadth of the architecture is so wide that it's hard to envision how anyone could build a business case that covers it all. It's like trying to boil the ocean.
A better scenario would be to make a business case based on a job that needs to be done (or currently gets done in a cumbersome way) and make a business case specific to that job that needs doing. Maybe it's building reports with BI Publisher, or putting together some dashboards with OBIEE, or building a custom process with BPEL. Take a small case and limit your scope, then write a business case for resolving the issue with a small piece of SOA. Stick to essential features, which will keep the cost down, and bring it up quickly. Bring in your SOA incrementally, piece by piece in a way that makes sense, rather than attempting to swallow the entire pill at once. Any guesses on the process I'd recommend following to bring up your first SOA increments?
We could apply the same approach to implementing Enterprise Applications. Chuck most of those ugly written deliverables into the garbage…nobody reads them once the implementation is done anyway. Substitute "conference room pilot" for "UI Prototype" in the steps listed above. Switch out "back-end coding" for conversions, interfaces and bolt-on customizations. Looks much more do-able in a shorter time span now, doesn't it?
I think this stuff applies in many more areas of life, both inside and outside of IT. Looking forward to hearing your thoughts in the comments. In the meantime, you can check out 37Signals at signal vs noise.
1. Learn about the job that needs to be done (which is very different from just gathering requirements).
2. Stick to including only essential features
3. Put up a UI prototype based on what you know.
4. Gather feedback on your prototype.
5. Revise your prototype for the feedback you receive.
6. Repeat steps 3 and 4 until you get something worth putting up in production.
7. Build the necessary back-end coding.
8. Put your app up in production
If your app needs more after the first production release, rinse-wash-repeat.
The upshot here is to get up and do something...just do it. The book also suggests that this technique applies to much more than web apps and, after some consideration, I agree.
Last week, I had the good fortune to attend an OTN Architecture Day focused on SOA. The major concerns I heard repeated by others in attendance: it's darn near impossible to make a strong business case for SOA. And they're right. When you just consider Oracle's flavor of SOA, the breadth of the architecture is so wide that it's hard to envision how anyone could build a business case that covers it all. It's like trying to boil the ocean.
A better scenario would be to make a business case based on a job that needs to be done (or currently gets done in a cumbersome way) and make a business case specific to that job that needs doing. Maybe it's building reports with BI Publisher, or putting together some dashboards with OBIEE, or building a custom process with BPEL. Take a small case and limit your scope, then write a business case for resolving the issue with a small piece of SOA. Stick to essential features, which will keep the cost down, and bring it up quickly. Bring in your SOA incrementally, piece by piece in a way that makes sense, rather than attempting to swallow the entire pill at once. Any guesses on the process I'd recommend following to bring up your first SOA increments?
We could apply the same approach to implementing Enterprise Applications. Chuck most of those ugly written deliverables into the garbage…nobody reads them once the implementation is done anyway. Substitute "conference room pilot" for "UI Prototype" in the steps listed above. Switch out "back-end coding" for conversions, interfaces and bolt-on customizations. Looks much more do-able in a shorter time span now, doesn't it?
I think this stuff applies in many more areas of life, both inside and outside of IT. Looking forward to hearing your thoughts in the comments. In the meantime, you can check out 37Signals at signal vs noise.
Saturday, May 15, 2010
Some Things Take Root
No, I'm not writing about Unix or Linux root, as fitting as the title would be for that. I'm actually writing about experiences that are so positive that they take hold of us and make us want to repeat them. Much like a seed taking root in the ground, these experiences take root in us. Some things really take root with me.
Participating in the user feedback labs from the Oracle User Experience team is one of those experiences that has taken root with me…I do it every chance I get. My most recent experience was at Collaborate 10.
I started off spending some time with Erika Noll Web (one of Oracle's User Experience Managers) and Sid Chilakapati (a Project Manager of Oracle's Fusion Applications Support Team). We spend a significant amount of time talking about the potential for light-computing applications with the iPad and the iPhone. The conversation grew to include the Android operating system as well (Sid's an Android guy). We also ran through some changes Oracle has in mind for My Oracle Support - drilling down into research by product and business process. As a functional guy at heart, what I saw rocked…hope it makes it to the light of day. Also put in a serious plug for dumping Flash in My Oracle Support in favor of HTML5, so I can do research on a mobile device. Great conversations with very bright people who went out of their way to make me feel at ease.
I also managed to get in some time with my old pal Santosh Astagi, whom I've talked about before here. This was a windfall - I had some time booked with him early in the day and had to miss out because of another meeting conflict that popped up. So I felt fortunate to get in some time with Santosh. He still has that same easy-going, no pressure style of gentle guidance that I appreciate some much when working through user experience testing. The guy is a master of capturing the essence of your feedback while keeping you comfortable, even if you struggle a bit. We worked through a Thematic Maps prototype that looked pretty spiffy to me…a couple of sticky points, but most of the user experience elements were already working pretty well for a prototype. A pic of the master and me here.
So again, the user feedback lab sessions were good experiences for me. The welcome was warm as I checked in for my feedback sessions. Heck, even the freaking' cookies were good! Seriously, kudos to Oracle's Gozel Aamoth, Lulit Bezuayehu, and Teena Singh for putting these feedback sessions together…this team really pulls it all together. A pic of the team here…hanging with some ugly old bald troll.
Now, I know what you're thinking…why in the world should you spend times at labs like this? Well, I think you get three things from it: 1) it's a window into the new efforts coming through the Oracle development pipeline; 2) this is a pretty direct means of getting input into Oracle's development of new products - if you don't like what you see, these folks are taking that back to the product development teams…and I've seen first-hand the changes resulting from that input; and 3) it's fun! Give it a try once and see if the experience takes root with you. I'm sure they'll be running more user feedback session at Oracle OpenWorld this year.
I wonder if there's a user feedback lab at the OHUG next month?
Subscribe to:
Posts (Atom)