Sell your Boss - Some Tech Observations
Sell your Boss - Some Tech Observations Saw this great post from Hyatt (referred from this blog, definitely worth syndicating) re: how to get decisions / results out of your manager / boss. Great stuff, pay attention to the details here, all of it is right on. A few additions I'd make to the list ...
- Keep it short - just like you, your boss is juggling multiple priorities, especially when you're reporting to a C-level person. If you can't develop and present an elevator pitch version of the story, you risk losing their attention span. It's not that they are dumb - far from it. More like their mind is completely in another place, and you are asking them to take a sharp 180.
- Relate Projects / Requests to Corporate Objectives - tied to item #1 in Hyatt's article, but be very specific. Why do they care about barcode printers? Because it's the only way they can deliver on the Quality Improvement promise they made to the Board!
- Order of Bullet Points is key - which approach is more effective?
- We need barcode printers, so we can print labels and bounce-back cards, so we can gather information and write reports, so we can quantify quality issues, something the Board has been promised.
- The board expects Quality metrics. We have no ability to gather these metrics, so we need to implement this new process. To complete the effort, barcode printers must be purchased.
Beleive me, the second one works better because you are telling them why they care, right up front.
- Focus on Business: I've had a range of managers over the years, and while they have all been at varying levels of technical skill, it's always most interesting to try and have technical discussions with the non-technical managers. They usually don't appreciate the technical nuances .. because they rarely matter. Must focus on the business benefot, not the technical fine points.
- Skip Cliches: Tight budgets got you down? Please know that all of your peers, all of your competition for budget, most likely will be feeling the same pain. Key is to steer clear of the "gotta spend money to make money" pitch - you are talking down to them, over-simplifying the budget process that they have painfully gone through.
Technorati Tags: boss, communication, pitchLabels: business value of IT
Meme-jumping: Fun with Bloglines
Meme-jumping: Fun with Bloglines Backwards recursion to boncey.org, far be it from me to break the chain.
- Go to bloglines (donât think you need to have an account).
- Find your own blog on bloglines (if itâs not there you can sign up and add it I guess, if you donât have a blog this oneâs not for you).
- Click related feeds (each time you click they may change slightly).
- Post the top 5 (or more) on your blog.
Here are my top 10:
- World Wide Web Consortium
- Chris Pirillo
- MSDN Just Published
- Microsoft Watch from Mary Jo Foley
- The Register
- Google Weblog
- Slashdot:
- you've been HAACKED
- Neowin.net Gamers
- http://blogs.msdn.com/jobsblog/
wow, that's nothing like what I would have expected. Makes me sound like a MS junkie who likes to hack. I know a few like that, but would not consider that to be an indicator of my style. Maybe I need to write more ...
|
The good and the bad about being a hands-on tech manager
The good and the bad about being a hands-on tech manager Interesting project that I have to take a deep-dive on this week - has to do with automating a piece of barcode printing software, and integrating it with a newly developed labeling process out in the shop. Project was hitting some significant snags, and I was asked to step in. Here's where hands-on software development skills are a boon and a curse ...
The perception is that we're trying to get the forms software to work in a certain way with the scanner; we'd like to minimize the interaction with the keyboard and eliminate the need for the mouse.
Note: Classic problem with the focus on GUI interfaces - everybody makes their forms / software work with a click of the mouse. Problem is, folks in a shop environment do not want to have to stop, find the mouse, find the cursor, click the button - it just slows them down. Sorta the same thing with data entry folks - they learn their keyboard and become quite fast, so make sure the app can be easily navigated using only the keyboard. Also - you'll need to / be able to mimic keyboard entries with the scanner (and you can't mimic mouse movements with a scanner).
Boon: Knowing how to anticipate user calls and complaints, and how real people interact with software, is a soft skill you can never underestimate.
Curse: Ya gotta be careful not to take over a developer's effort, as they want to be able to express their own experience / develop their own skills.
The feeling was that we were struggling with the forms software and it was buggy, and I was asked to push the vendor for some tech help. First step, however, was to get a better, cleaner definition of the problem.
Note: Benefit of experience speaking here ... this vendor is not a huge software house (heck, the stuff was written in England, these guys are just a VAR), and I knew we'd get little direct help - no bandwidth, not a hugely expensive piece of software. My actual approach was to define the root issue very simply, as we could probably devise a workaround or fix a bug in our thinking / implementation that was lost on the details.
Boon: When you know what it's like to be on the receiving end of these "help me" calls, you know how to pose the question to get maximum results when you finally do get a tech support person on the line.
Curse: Here's where I start getting sucked into the details of the project, which is good (because it's a strategic effort and we need to get back on schedule) and bad (because it's taking me away from 3-4 other key things on my todo list).
So, we developed a single form, with a single data field and single button. The goal was to get the scanner to fill out the field and press the button to print. The trick - and we sorta reverse-engineered / trial and error'd on this - was that the data field does not save your input until the field sees a LostFocus event. "Pressing return" (via scan) to make the button go does not gen this event, but mouse clicks and keyboards do.
Note: Even though the software has VB Script, it did not expose any objects, properties, or methods for us to program / change / trap. Still, knowing how Visual Basic or similar would work, we use those concepts to express what is happening.
Boon: Hands-on programming experience helps you develop a very specific definition of the problem; soft skills are required to make sure we clear away / remove all variables that don't have anything to do with the root problem.
Curse: This is more of a curse on the project team - when I get involved to this level, I am "looking over their shoulder" in excruciating detail, and they cannot hide behind techno-jargon.
Turns out this makes sense if you imagine how a form with multiple fields would / could / should work. Bottom line, we realized the end user will have to scan the label (which will automatically tab to next object [field or button]) and then scan a code to hit enter.
Note: When analyzing how the software works, you can't limit your thinking to how we want it to work; have to understand why it was designed this way - possibly for other / more complex / different forms?
Boon: Experience allows you to draw on old programming / implementation projects for examples of different ways to do forms / scanning / data capture (for example).
Then, we found out that the mechanics of the forms processing software did not give us enough hooks to add code that did what we wanted - like blanking out an input field and positioning the cursor wherever we wanted. The forms object is not exposed enough to us - only simplistic VB Scripting allowed. So, we opted to punt and scramble to create an Access mini-application that will manage the read/write to the database, plus the screen actions that we want.
Curse: Nothing like realizing in excruciating detail that we'll have to toss out a good chunk of code and do a rewrite using a different "platform" - MS Access, in this case. Still, it's nice to have that kind of back-up solution in your pocket.
That was all yesterday. Today's task - to see how fast we can completely rewrite the basic application!
Technorati Tags: vbscript, barcode, management,
Excellent analogy for understanding long-term cost of maintenance
Excellent analogy for understanding long-term cost of maintenanceCheck out
this article by Chad Dickerson, it's a terrific analogy for understanding the long-term cost of maintenance that the business must accept when requesting / dealing with custom software.
Technorati Tags: cost, management, maintenanceLabels: business value of IT, tech management
Motivating Maintenance Programmers
Motivating Maintenance Programmers Interesting conversation today with one of my application managers. As we move into the new year, we're doing some "spring cleaning" of the older projects in our PMO. Two from last summer had languished - efforts to develop simple web front ends for order inquiry and dealer information - and I asked my lead web developer to audit them (make sure we've got source code under version control, check out the tech architecture for the supporting database, etc.) before "closing" - putting them on hold until later.
The application manager took some exception; they had been involved in the design and execution of the project, and were surprised when I asked someone else to close out the project. My intentions were good, as the app manager is currently swamped with maintenance programming, simple query requests, & operational support, and did not have time to deal with the administrivia of cleaning up the project. At the same time, this person is continually proposing new projects and initiatives on their current platform, seemingly determined to maintain the viability and long life of the underlying application. When, exactly, are we supposed to do "new" work on other platforms?
It is possible to provide a "path to the future" for so-called "legacy" platforms and application support; success, however, depends on deliberate planning as well as the open minds of the maintenance programmers themselves.
- It's the Developer's Responsibility / Task / Duty
Actually, this zen is more along the lines of existentialism and keeping the open mind - life is what you make it, etc.
If you feel like management isn't moving fast enough, why wait? You have a lot more control than you might think, but one of the biggest mental blocks to get through is the need to Let It Go. You can't work on the new stuff unless your finished with the old stuff (good quote embedded here). Typical technical mentality is to make yourself irreplaceable - job security. The expectation/desire is that IT management will take you out of your boring maintenance work, and give you something "fun" to work on. Problem is - who will take on the boring stuff?
Heck, why make that the manager's problem? Why wait around for somebody else to take on the Thankless, Joyless Work. Force the issue by Eliminating the Thankless, Joyless Work. In a very real sense, you need to work towards eliminating your job - and no, I'm not saying this because I like it when staff makes it easy to lay them off. Quite the contrary: the real value of the internal IT group should be based on their knowledge of the business and their ability to translate that to technology - any technology, not COBOL or RPG or BASIC.
- It's the Manager's Responsibility / Task / Duty
The "deliberate planning" approach - there are many ways to use organization and process to enable the "path to the future".
One specific example from our group - we manage all support / programming requests in our PMO, and aggressively review and prioritize the requests to make sure we're only working on the critical stuff. Programming is not always the answer - just because you can do something doesn't mean you should. We stress simplification, sticking to standard product and process in our big ERPs, and justifying all programming requests with a clear business case. No, it doesn't prevent all the questionable requests from getting through, but it helps.
Another specific example is the use of staff augmentation and contractors. The danger with business-sponsored projects is the managers want results as fast as possible, and invariably feel its faster to RAD for the business requirements with consultants who know the technology. The other option, more friendly to the tech aspirations of the internal developers, is to train existing staff in the new technology, and use contractors to backfill the maintenance work.
Caveat: The basic question (easier to train someone the business or the technology) does not always get the same answer. Some new technologies are true conceptual and architectural leaps for developers on different platforms. Still, this is an area where the developer can tip the scales in their favor by proactively, on their own time, get involved with new technology. It's incredibly easy - this entire site is constructed with technologies that do not exist in our shop.
So, back to my application manager. How did I resolve the concerns?
The key messages were to make sure we kill the backlog and reduce the amount of maintenance work that is currently swamping us. I'm not talking about working 90 hour weeks to deliver every program request - we're stressing the prioritization approach. In addition, we do pitch the backfill approach for contractors on projects, and stress the business knowledge of our internal staff to the project sponsors involved.
Was I successful? Yes and no - this application manager needs to concentrate on the Let It Go message, to develop the self-confidence that the company appreciates their longevity and their knowledge. It can be tough to coach people on how to think.
Technorati Tags: techmanagement, management, motivation,
Back in the Swing, Jump on the Bandwagon
Back in the Swing, Jump on the Bandwagon Yes, I definitely need to get back in the habit of posting here - can't always blame skipped days on the crazy demands of the job - but it has been an interesting holiday season.
Still, need to rededicate (no, I don't believe in New Year's resolutions) myself to the posting of the blog. Today's topic - self-referential as it is - is blogs / blogging.
But I think the interesting threads out there are talking about how the blog as a medium is evolving. For example ...
- Doc Searls pulled together some links on how "traditional" journalism is problematic because the journalist has become part of the story
- Some have decried the super bloggers, but Evelyn Rodriguez writes nicely about the value of the "personal voice" of personal bloggers
- Pierce is writing about the blog as a marketing tool.
- Infosential just posted about blogs as a project management tool
- The blog traffic on the SE Asia tsunami has been historic, and is driving the growth / maturation of picture blogs, even creating a new "category" of video blogs
Key is that this blog is attempting to mature into an element of my "personal branding" efforts, definitely a work in process, but one that must continue to get a nice chunk of time carved out for it through the course of the year. Lots of backed up material, just need to dedicate the time ...
