A president of a technology organization has been very successful in satisfying a rather narrow vertical in a niche market. Under his guidance, a custom-crafted data warehouse and reporting engine developed over three years has been successfully deployed to his highest profile clients. This reporting engine was the result of a decade of this president's experience and development in this vertical.
The president, seizing on a new but potentially lucrative revenue stream, now wants to apply this data warehouse and reporting engine to a new domain, but one using a new report query methodology with frequent use of highly cross-tabulated data. The president brings in an experienced professional outside the technology team to lead the construction of software to support this new report query methodology.
After a review of the problem domain and the current data warehouse architecture, the team lead demonstrates that the current architecture will not store the data effectively, or quickly execute the queries in the new lucrative domain. The new team lead reports on the expected size and structure of data, and a potential architecture to support storing and executing the new report queries.
The president, disturbed by the team lead's negativity towards the older engine and data model, declares that this is not what he wants. The president tells the team lead to take the current engine and "fix it, make it better, but we can't redo it otherwise we're deviating from our platform. I don't want two platforms. We spent three years building this platform and we must use it."
The team lead, seeing the incompatibility of the current data model, asserts that a new data model and reporting query engine would need to be constructed, and that a new architecture could be backwards-compatible with the reporting queries from the president's current niche market. The team lead provides a working engine and database to demonstrate the new architecture's viability, integration with features of the current platform, and ease of construction to satisfy this new domain.
The president, after conferring with the older members of the team, is more disappointed than ever. But the other members do not have a strong alternative to the new team lead's solution. Not being technical but always willing to contribute technically, the president makes a few technical short-cut style suggestions. One suggestion is plausible to the new team lead, but the others have no connection to the new reporting query engine requirements.
A few of the technical team members take a look at the team lead's work and begin to agree with the team lead. But the president still does not come to an agreement with the team lead's assessment. Soon after, the team lead is off the project, while the president continues to search for a solution.
Should the president expect a custom data warehouse that took three years to construct, and that was fully paid for by the company, to be usable towards every revenue stream the president wishes to tap? Or does the president need to let this go and move forward?
Should the team lead reference the technical knowledge and experience accrued over time to make an assessment? Or, because of the new domain, should the team lead let this go and move forward?
Who is right in this situation? The president? The team lead? Keep in mind that what is most wrong with this situation is that the lucrative revenue stream remains untapped.
It can be difficult for us to let go of our past ideas and our creations in order to move forward, but in some cases this is actually what is needed to make the best of our present state and lead us to our future successes. If faced with a similar decision, do you think you could let go?
Showing posts with label leadership. Show all posts
Showing posts with label leadership. Show all posts
Tuesday, May 5, 2009
Wednesday, February 18, 2009
Resolving our Top Priorities
At one point in my career I became champion for one of the most critical projects for an organization - one whose previous lack of focus on completion had already caused harm (including physical damage) to the organization twice in two years. As such, this critical project had been labeled "top priority" for this organization.
As champion, I had been dissatisfied with the lack of management focus on this top priority project, and brought this to the organization's attention. I was given a stern reminder by management that this goal was one of five or six top priority projects, and that the resources and focus necessary to complete this goal would be utilized across all five or six projects as they were available. And in the months that followed, this project did not experience the appropriate increase in focus as it continued to compete with the other projects for attention.
In your organization, is there an actual "top" to the list of priorities, or is it more of a raised plateau of several priorities all seeking to be fed? Can any of the following priorities for an organization be considered absolutely Priority One:
- Generating new leads
- Delivering increased product
- Bringing the next technological innovation to the marketplace
- Replacing aging infrastructure with current or next-generation systems
- Reorganizing to maintain competitive advantage
- Generating enough revenue to keep the lights on
Certainly every organization needs to do all of the above, and needs to do them well in order to thrive in the marketplace. It seems impossible for many organizations to focus on one of these priorities over some of the others, but some careful examination may yield more clarity in addressing priority:
- Do these priorities compete with each other?
- Do they complement each other?
- Does the completion of objectives of one priority facilitate the completion of objectives in another priority?
- Will our resources be able to address one or more of our priorities while covering business-as-usual responsibilities?
These may be simple questions that require intensive analysis to answer, but it is worth re-reading the questions often when we start to lose ourselves in tools, charts, and numbers. It is also worth reminding ourselves that allocating and juggling six top priorities really amounts to seven in number - one priority is the actual juggling effort that takes place while trying to manage the other six priorities.
Another consideration is where in the organization these priorities need to be addressed. There are areas in an organization where priorities and responsibilities must be partitioned in parallel, and there are areas that must be focused on a top priority objective. The management of the organization above had not quite figured out the optimal locations of partition and focus.
As many of my readers know, this is not as simple as a top-down partitioning and arrangement of responsibilities. An organization's current structure and its culture can greatly help or greatly hamper this analysis. You see evidence of this when organizations announce numerous reorganizations and restructures within the span of two or three years. They are still seeking the proper structure of partition and focus to complete top priority objectives. Or worse, they are seeking the proper structure that will help them define their top priority objectives.
If your organization is experiencing uncertainty with juggling or establishing an order for top priorities, try taking on at most TWO top priority objectives at once, one primary and one secondary. This way your organization will have TWO objectives completed rather than five or six that remain suspended in a perpetual juggle-state. In today's marketplace, juggling priorities is not an excuse for lack of completion of any one or two top priority objectives.
As champion, I had been dissatisfied with the lack of management focus on this top priority project, and brought this to the organization's attention. I was given a stern reminder by management that this goal was one of five or six top priority projects, and that the resources and focus necessary to complete this goal would be utilized across all five or six projects as they were available. And in the months that followed, this project did not experience the appropriate increase in focus as it continued to compete with the other projects for attention.
In your organization, is there an actual "top" to the list of priorities, or is it more of a raised plateau of several priorities all seeking to be fed? Can any of the following priorities for an organization be considered absolutely Priority One:
- Generating new leads
- Delivering increased product
- Bringing the next technological innovation to the marketplace
- Replacing aging infrastructure with current or next-generation systems
- Reorganizing to maintain competitive advantage
- Generating enough revenue to keep the lights on
Certainly every organization needs to do all of the above, and needs to do them well in order to thrive in the marketplace. It seems impossible for many organizations to focus on one of these priorities over some of the others, but some careful examination may yield more clarity in addressing priority:
- Do these priorities compete with each other?
- Do they complement each other?
- Does the completion of objectives of one priority facilitate the completion of objectives in another priority?
- Will our resources be able to address one or more of our priorities while covering business-as-usual responsibilities?
These may be simple questions that require intensive analysis to answer, but it is worth re-reading the questions often when we start to lose ourselves in tools, charts, and numbers. It is also worth reminding ourselves that allocating and juggling six top priorities really amounts to seven in number - one priority is the actual juggling effort that takes place while trying to manage the other six priorities.
Another consideration is where in the organization these priorities need to be addressed. There are areas in an organization where priorities and responsibilities must be partitioned in parallel, and there are areas that must be focused on a top priority objective. The management of the organization above had not quite figured out the optimal locations of partition and focus.
As many of my readers know, this is not as simple as a top-down partitioning and arrangement of responsibilities. An organization's current structure and its culture can greatly help or greatly hamper this analysis. You see evidence of this when organizations announce numerous reorganizations and restructures within the span of two or three years. They are still seeking the proper structure of partition and focus to complete top priority objectives. Or worse, they are seeking the proper structure that will help them define their top priority objectives.
If your organization is experiencing uncertainty with juggling or establishing an order for top priorities, try taking on at most TWO top priority objectives at once, one primary and one secondary. This way your organization will have TWO objectives completed rather than five or six that remain suspended in a perpetual juggle-state. In today's marketplace, juggling priorities is not an excuse for lack of completion of any one or two top priority objectives.
Monday, January 5, 2009
Leading the Way In Technology and Business For 2009
2008 notwithstanding, this year is shaping up to be one that will truly change the playing field of business; the one that will introduce new competitors to the landscape while retiring others. Perhaps, like me, you have begun to ask - who will lead the way?
Well, the one answer that I propose that you consider is YOU! When you examine the usage of your technology to run your business, ask yourself if you are leading the way:
- When you must examine your daily sales or P&L reports at 9 pm, only because "they cannot possibly be produced any earlier", are you leading the way?
- When your intranet web application needs a twice-daily reboot during the most critical portion of the business day, adding an extra hour or more to your business principals' workday, are you leading the way?
- You've approved the $350k middleware solution and the matching salary overhead to produce a critical automated data pipeline. Yet six months later, your technologists are taking turns arriving early at 6 am to manually start up the first few stages of the pipeline, and once or twice a week this is inevitably delayed. In addition, your technologists are heroically correcting data and processing errors in-flight several times a week. Are you leading the way?
- When, after a long day's work, you are logging into your organization's systems every night at 3 am, just to watch the overnight jobs run and "make sure" that nothing goes wrong, are you leading the way?
- When a major data stream is unavailable during a critical processing period, and no alternative streams or pipelines exist, your business process is delayed indefinitely. During this delay, are you leading the way?
Like most of you, these are just a few of the many issues that I have had hands-on experience addressing and resolving for the benefit of our businesses. Perhaps you and I also have produced some issues of our own that needed a different angle of consideration, a different path to success. Resolving these issues, and many more like them, is what we leaders must strive for.
So, for 2009, will the way you use technology give you the confidence to run your business well, handle the exceptions that arise, and allow yourself to sleep? Will your technology let you and your business lead the way?
Well, the one answer that I propose that you consider is YOU! When you examine the usage of your technology to run your business, ask yourself if you are leading the way:
- When you must examine your daily sales or P&L reports at 9 pm, only because "they cannot possibly be produced any earlier", are you leading the way?
- When your intranet web application needs a twice-daily reboot during the most critical portion of the business day, adding an extra hour or more to your business principals' workday, are you leading the way?
- You've approved the $350k middleware solution and the matching salary overhead to produce a critical automated data pipeline. Yet six months later, your technologists are taking turns arriving early at 6 am to manually start up the first few stages of the pipeline, and once or twice a week this is inevitably delayed. In addition, your technologists are heroically correcting data and processing errors in-flight several times a week. Are you leading the way?
- When, after a long day's work, you are logging into your organization's systems every night at 3 am, just to watch the overnight jobs run and "make sure" that nothing goes wrong, are you leading the way?
- When a major data stream is unavailable during a critical processing period, and no alternative streams or pipelines exist, your business process is delayed indefinitely. During this delay, are you leading the way?
Like most of you, these are just a few of the many issues that I have had hands-on experience addressing and resolving for the benefit of our businesses. Perhaps you and I also have produced some issues of our own that needed a different angle of consideration, a different path to success. Resolving these issues, and many more like them, is what we leaders must strive for.
So, for 2009, will the way you use technology give you the confidence to run your business well, handle the exceptions that arise, and allow yourself to sleep? Will your technology let you and your business lead the way?
Thursday, October 2, 2008
Leadership During Downtime
When I browsed to LinkedIn early this morning, this is what showed up on a web page entitled "Oops!":
For many developers and business users of web applications, this is an all-too-familiar sight when a web site is experiencing problems. But does it need to be?
LinkedIn is no doubt a leader in on-line networking and community. But while there is a link to contact customer service via email, the web page is pretty much out of character with the rest of the web site: no ads, no links to its user community's services and sites, no information about LinkedIn itself - in other words, nothing useful. We might as well have received the standard error page from the browser.
In a period of downtime, LinkedIn is missing out on an opportunity to continue leading the way as a premier networking and community portal. Just a few links and paragraphs of text can make all the difference, so that during downtime LinkedIn would never be completely offline.
Sorry, we can't display this page right now.
Something unexpected has gone wrong. Please wait a few seconds and try again by hitting the reload button.
We apologize for the inconvenience. An error report has been filed and our team is working on fixing the problem.
If you have any questions, please email us at customer_service@linkedin.com.
For many developers and business users of web applications, this is an all-too-familiar sight when a web site is experiencing problems. But does it need to be?
LinkedIn is no doubt a leader in on-line networking and community. But while there is a link to contact customer service via email, the web page is pretty much out of character with the rest of the web site: no ads, no links to its user community's services and sites, no information about LinkedIn itself - in other words, nothing useful. We might as well have received the standard error page from the browser.
In a period of downtime, LinkedIn is missing out on an opportunity to continue leading the way as a premier networking and community portal. Just a few links and paragraphs of text can make all the difference, so that during downtime LinkedIn would never be completely offline.
Wednesday, September 24, 2008
Getting Our Hands Dirty
During my career I've gained deep experience with financial software development, management, and leadership. But for many years I also provided on-call after-hours and overnight system support, first on a rotating-schedule basis, then 24/7/365. From this I learned the most critical details of what works and what does not work regarding data architecture, data transmission, business workflow, information flow, and human communication pathways within an organization. Learning these critical details often requires us to get our hands dirty, as this true story demonstrates:
One company’s hot-stove issue of the day was the paper problem: "We're spending so much on paper! Most of our paper reports are printed overnight at 5 am. Why do we print out so many reports overnight?" To be sure, this problem represented a sizable cost during a company’s belt-tightening period that required the Business and IT to conscientiously team together to get to the heart of the issue.
The long-tenured business-side Managing Director and the recently-hired CTO sat in the same room with a few key people from both Business and IT, to discuss the issue with the overnight support specialist responsible for collating and distributing the reports. After a few discussions on the purpose of the reports and the distribution lists, no clear solutions were presented. It was then the CTO declared, “Well if I have to come in at 5 am and see what is going on myself, then that’s what I’m going to do!”
A week passes by. Did the CTO make a call to action, or come in at 5 am? No - not even once. But one developer did not have to come in at 5 am to examine the company’s internal report-generation schedule and discover several large reports being generated and printed in duplicate, all delivered to the same recipient. In just a few hours after that meeting, the development team removed the duplicates from the report-generation configuration, alleviating some of the printing headache and cost beginning with the next night’s report run.
But the developer went further than that, as he had done previously when investigating IT problems in his company - he DID come in overnight and got his hands dirty. He sat with the overnight support specialist and analyzed when the reports were actually electronically delivered, how the specialist was collating and distributing the reports, and documented their purpose. After reviewing the developer's findings, the Managing Director agreed that most of the non-duplicate printing and distribution justified the cost for the time being, until the Business could get a paper-less business process in place.
When the buzz of the CTO’s declaration died down, the CTO was not willing to get his hands dirty. And what could have been a defining and inspiring leadership moment ended up being an action-less statement. But one developer took the lead, providing some immediate relief, but also investigating the problem in-depth and providing a basis for discussing a long-term solution. The developer was recognized by the Business for his leadership, while the CTO moved on from the company shortly thereafter.
The developer here learned that getting your hands dirty can produce results, and that leadership often requires that we get our hands dirty when investigating problems and formulating solutions. As today’s Leader – are you willing to get YOUR hands dirty?
Tuesday, September 16, 2008
A blog is born...
Welcome to my latest venture! This is the place to read about and discuss why effective leadership in uniting Business and IT goals and groups is so crucial for organizations, as they thrive and work to maintain their edge in a competitive marketplace.
This blog will cover:
- topics on leadership and unity of Business and IT groups of thriving organizations
- real-world anecdotes of effective (and not-so-effective) technology and business leadership
- people profiles and topics, to consider some outside viewpoints
- what it means to be an Exception-Tolerant Organization (ETO). I will flesh out this concept and its principles and practices in the coming days.
Who should read this blog:
- technologists of all levels looking to make a greater impact in their work and their organizations, and actively working to sharpen their growing edge of leadership
- business owners, executives, managers, and associates seeking more fulfillment and assistance from their IT groups and partners in accomplishing their business objectives
I hope that the blog will provide insight and open up a dialogue to improve leadership at all levels of an organization as we face the challenges ahead of us in the rest of 2008 and beyond.
Happy Reading!
Jason Sliss
This blog will cover:
- topics on leadership and unity of Business and IT groups of thriving organizations
- real-world anecdotes of effective (and not-so-effective) technology and business leadership
- people profiles and topics, to consider some outside viewpoints
- what it means to be an Exception-Tolerant Organization (ETO). I will flesh out this concept and its principles and practices in the coming days.
Who should read this blog:
- technologists of all levels looking to make a greater impact in their work and their organizations, and actively working to sharpen their growing edge of leadership
- business owners, executives, managers, and associates seeking more fulfillment and assistance from their IT groups and partners in accomplishing their business objectives
I hope that the blog will provide insight and open up a dialogue to improve leadership at all levels of an organization as we face the challenges ahead of us in the rest of 2008 and beyond.
Happy Reading!
Jason Sliss
Subscribe to:
Posts (Atom)
