It's often said that most start-ups go through several pivots before they get to some form of market success. That pivot might be the product, its target audience, or the delivery (such as turning the product into a service). Such outward-facing effects change the way the company is seen by potential investors as well as customers, shaping the chance of success.
It is also almost always the case that there are internal pivots that shape what the company is, & what it looks like to itself (& to its board), & how it does business. Although multiple pivots can happen, there is usually only one that stands out in the history of the company - & I would like to christen it the "'This is Serious!' Moment" (TISM) in honour of a now-forgotten indie band of twenty years ago that had nothing to do with the rest of this article. This is separate from, but often related to the "Holy Cow!" moment (HCM) when things suddenly pivot for the better after a lot of hard work.
At some point, founders will gather in the garage or around the little table in the kitchenette of the office & know that, very soon, they won't be allowed to make world-shattering decisions by scrawling on the back of a bad printout, because everything they do is now more important. Often, this internal realisation is accompanied with a flurry of very corporate activity like hiring a CFO to actually be responsible for finances, or a project manager to guide releases - a layer of governance that doesn't sit well with a seat-of-the-pants operation, but is essential when things start to become serious.
Sometimes, you can miss the "This is serious!" moment because it happens immediately after the "Holy Cow! Someone gave us money!" moment (HCM), & that heady experience of losing your doubts over success - if only for a day or two - makes you miss the fact that, not only have you asked "What next?", but you always knew the answer - things get more serious.
Some companies seem to never grow up, never have a TISM - but it's always an internal moment, & almost always before the company goes public. You'll find that moment buried in the middle of biographies & exposés. It doesn't have much significance in itself, because every company does it, but no company that succeeds didn't do it. Google's TISM was probably hiring Omid Kordestani for sales. In the case of Microsoft, it was probably the move to Washington after successfully divorcing from MITS (eerie coincidence of letters).
Strive for the HCM, plan for the TISM. Don't get left wondering "What next?"
Wednesday, November 25, 2015
Continuous Improvement as a Business Transformation
One of the key benefits of an agile methodology like Scrum - & something that is very hard for a non-developer to get their head around - is that the methodology encourages & assumes some form of continuous improvement. There is regular reflection on the process as implemented, & how it can be made to work better.
Something that is much better understood at a corporate level than it is within an IT team is a business transformation process (or project), which sets the goal of achieving particular outcomes in some parts of the business as a result of a specific set of changes.
These are, more or less, equivalent.
Having said that, they are never seen as such for one very simple reason - one is iterative (usually based on a sprint of, say, two weeks), while the other is waterfall (lots of design up front, big delivery at the end of the project).
It is generally as a result of this divide that there are perceived differences like:
However, it will only add value if you can measure the outcomes. Anything that adds value can generally add the right kind of value (efficiency, cost reduction) if you set the right goals & measure the effectiveness of investment.
Too often, an IT unit "goes it alone" to improve itself because there is no executive buy-in for a business transformation process that is not a project that appears in an annual budget. Too often, executives see the internal workings of an IT unit as too arcane both for them & their board.
However, when the way that IT units work becomes the focus of a business strategy - with measurable outcomes - the business can only get better at measuring its own likelihood of success.
Something that is much better understood at a corporate level than it is within an IT team is a business transformation process (or project), which sets the goal of achieving particular outcomes in some parts of the business as a result of a specific set of changes.
These are, more or less, equivalent.
Having said that, they are never seen as such for one very simple reason - one is iterative (usually based on a sprint of, say, two weeks), while the other is waterfall (lots of design up front, big delivery at the end of the project).
It is generally as a result of this divide that there are perceived differences like:
- continuous improvement rarely plans ahead, setting goals against which they measure their progress in improving
- business transformations produce isolated results in unrelated projects
- continuous improvement produces a trend of live status which is often out of date as soon as you print it
- business transformation has success criteria defined that ensure that a project ends & its approved budget can be classified into accounting periods & closed off
However, it will only add value if you can measure the outcomes. Anything that adds value can generally add the right kind of value (efficiency, cost reduction) if you set the right goals & measure the effectiveness of investment.
Too often, an IT unit "goes it alone" to improve itself because there is no executive buy-in for a business transformation process that is not a project that appears in an annual budget. Too often, executives see the internal workings of an IT unit as too arcane both for them & their board.
However, when the way that IT units work becomes the focus of a business strategy - with measurable outcomes - the business can only get better at measuring its own likelihood of success.
Monday, November 23, 2015
Development Methodology as a Business Strategy
Although it may not be trendy, it is still often the case that people say that they follow an Agile methodology, but usually explain it in terms of how the product development process happens in isolation of the rest of the business.
Regardless of the flavour of agile, the implementation of the processes should - indeed, must - align with the business strategy. Without some alignment, there is nothing at C-level to indicate that the engineering department is effective, except in terms of project success rate or marketing meeting its goals. To have a measure of effectiveness within an engineering department, then there has to be something measurable at enough detail to make predictions, set goals, compare, & assess.
Agile processes generally provide a framework for being more effective at developing product. The processes themselves need to allow for reflection & adaptability in an iterative sense - continuous improvement. Even if board-level decisions are not agile, the benefits of agile processes can - & should - lead directly into corporate strategy.
To give a concrete example, the cost of an engineering department is usually considered to be linear against resources. However, it is "well known" that a more effective team produces better product (cheaper to maintain & support, easier/cheaper to extend, faster to react to market needs). If there is a company strategy for producing better product (with a goal of lowering maintenance costs), then the process for achieving this - improving the effectiveness of the development team - needs measurable goals.
Candidates for measures - from a product development perspective - might be:
Now we can understand why a strategy is never applied to a development methodology - it takes a lot of effort to translate the language used in engineering into the language used in business strategy. It is not impossible, it's just the few people are doing it.
The first step is always the hardest. A board has to have goals that cover both outward-facing measures (P&L) & inward-facing (team effectiveness), & these have to be aligned by strategies that inter-relate & support each other.
Regardless of the flavour of agile, the implementation of the processes should - indeed, must - align with the business strategy. Without some alignment, there is nothing at C-level to indicate that the engineering department is effective, except in terms of project success rate or marketing meeting its goals. To have a measure of effectiveness within an engineering department, then there has to be something measurable at enough detail to make predictions, set goals, compare, & assess.
Agile processes generally provide a framework for being more effective at developing product. The processes themselves need to allow for reflection & adaptability in an iterative sense - continuous improvement. Even if board-level decisions are not agile, the benefits of agile processes can - & should - lead directly into corporate strategy.
To give a concrete example, the cost of an engineering department is usually considered to be linear against resources. However, it is "well known" that a more effective team produces better product (cheaper to maintain & support, easier/cheaper to extend, faster to react to market needs). If there is a company strategy for producing better product (with a goal of lowering maintenance costs), then the process for achieving this - improving the effectiveness of the development team - needs measurable goals.
Candidates for measures - from a product development perspective - might be:
- amount of time spent on rework (cost of problems found in testing)
- amount of time spent on re-implementation (problems found n the field - more expensive)
- estimation accuracy (for features or projects) - not just coming under budget
- velocity - the amount of work the team can do in a time period
- technical debt (the likelihood that something could go horribly wrong over time)
- alignment of skills to needs (training, staff turnover)
- false economies (where a cheaper option costs more because of knock-on effects)
Now we can understand why a strategy is never applied to a development methodology - it takes a lot of effort to translate the language used in engineering into the language used in business strategy. It is not impossible, it's just the few people are doing it.
The first step is always the hardest. A board has to have goals that cover both outward-facing measures (P&L) & inward-facing (team effectiveness), & these have to be aligned by strategies that inter-relate & support each other.
Product Development Strategy
If your core business is developing (supporting, maintaining) a product (or service), then your corporate strategy is usually focused on marketing/sales-oriented measurable goals such as unit sales or licensing revenue (or chargeability ratio), market share (or growth), or ROI for projects.
Essentially, these relate to SMART goals because the outcomes are measurable, but often what contributes to these goals are less measurable strategies - or are not seen as strategies at a corporate level. Essentially, the various approaches for achieving these outcomes should be quantifiable & comparable & relate to the goal.
Let's work through some examples. If your goal is to increase licence revenue by 10%, then you have several possibilities:
To take each of these in turn; if you want to sell more licences to an existing customer, then the product must be structured in such a way that this is feasible - that is, there are feature modules, or else the licensing is seat or transaction based. Without a product strategy that delivers these capabilities, you cannot use this strategy.
To raise brand awareness, you can market the product to new targets, but this can only be effective with good brand reputation - an infrastructure around product support & product supportability that ensures that field issues are dealt with in product planning, & that the product (or service) is identifiable (& differentiable) within the market. This can only come about in the way in which the product is developed - both in terms of its feature set, & its deployment & use (or customer engagement model).
Thirdly, to increase the perceived value of the product, you have to have a product strategy that aims to provide something beyond new features - a step up in a product's applicability or usefulness. Even if intending to pass on the costs behind providing the product (for SasS), you have to build a product that can measure its own costs & report on them. This may sound obvious, but without a strategy in place, you have no way of aligning product development to the corporate goals.
Essentially, a product is only as good as what you build it to be, but a product strategy should be good enough to support the whole of the business' expectations. If your business is wholly dependent on the product, then product development strategy becomes a board-level concern.
Essentially, these relate to SMART goals because the outcomes are measurable, but often what contributes to these goals are less measurable strategies - or are not seen as strategies at a corporate level. Essentially, the various approaches for achieving these outcomes should be quantifiable & comparable & relate to the goal.
Let's work through some examples. If your goal is to increase licence revenue by 10%, then you have several possibilities:
- sell more licences in the current markets
- expand into new markets
- increase the licence fee
- sell more licences with existing relationships (cross-sell, in-sell)
- find more customers (raise brand awareness)
- justify a price increase (added value, price restructure/passing on costs)
To take each of these in turn; if you want to sell more licences to an existing customer, then the product must be structured in such a way that this is feasible - that is, there are feature modules, or else the licensing is seat or transaction based. Without a product strategy that delivers these capabilities, you cannot use this strategy.
To raise brand awareness, you can market the product to new targets, but this can only be effective with good brand reputation - an infrastructure around product support & product supportability that ensures that field issues are dealt with in product planning, & that the product (or service) is identifiable (& differentiable) within the market. This can only come about in the way in which the product is developed - both in terms of its feature set, & its deployment & use (or customer engagement model).
Thirdly, to increase the perceived value of the product, you have to have a product strategy that aims to provide something beyond new features - a step up in a product's applicability or usefulness. Even if intending to pass on the costs behind providing the product (for SasS), you have to build a product that can measure its own costs & report on them. This may sound obvious, but without a strategy in place, you have no way of aligning product development to the corporate goals.
Essentially, a product is only as good as what you build it to be, but a product strategy should be good enough to support the whole of the business' expectations. If your business is wholly dependent on the product, then product development strategy becomes a board-level concern.
Saturday, November 21, 2015
Top Level IT Strategy
When I started getting involved with business architects, I was excited, because I thought - this is it, this is what ties what I've been doing (product development) with what I haven't been doing (running a company).
Eyes bright with wonder & enlightenment, there is still the question: why hasn't someone gone down this path before? Why is it that we think of IT (in the broadest sense) as only a business unit that supports the implementation of a company strategy, in terms of technology, or else as a unit that supports a sales/marketing strategy, in terms of delivering products & services?
Why is there rarely a top level strategy that sees IT units as an implementation of board decisions in themselves? Let me give you some examples.
If you're a non-IT enterprise (manufacturing, services, utilities, ...) there is an understanding of the IT needs of the business supported by an enterprise architecture & a plan to implement changes to the IT infrastructure to support financial strategies (say). Is there, however, a strategy governing the infrastructure that the financial strategy must align with? If not, then, as is often the case, each new implementation is a distinct & unrelated solution to an isolated problem.
If you're an IT enterprise, then your strategies are often around the deliverables of engineering departments - product releases, product strategy to compete, etc, but are there processes within engineering that directly support those strategies? If so, how do you ensure that they align - that they have the measurable outcomes that you expect, from a business point of view, to support the objectives of the company?
The short answer is that, without some form of business architecture - an understanding of how your business functions & the inter-relatedness of all units that contribute to the company's success - then not only can you not measure the impact of strategic decisions, but it is much harder to define strategies.
Right now, you're in one of two camps - "Great, I need a business architecture - where can I get one?" or else "My company is too small for that kind of stuff". The next step is the same, regardless. If your company has strategies & expects them to be implemented, then you need a framework to ensure that they are - across the organisation. If you don't have a framework, then your strategies are written in the sand & you hope that you're above the high tide mark.
I'm not going to say what framework you need, or even whether it needs to be a formal one, but without an approach to your IT/engineering departments that incorporates decision making into company strategy, you have an unmitigated board-level risk to deal with.
Eyes bright with wonder & enlightenment, there is still the question: why hasn't someone gone down this path before? Why is it that we think of IT (in the broadest sense) as only a business unit that supports the implementation of a company strategy, in terms of technology, or else as a unit that supports a sales/marketing strategy, in terms of delivering products & services?
Why is there rarely a top level strategy that sees IT units as an implementation of board decisions in themselves? Let me give you some examples.
If you're a non-IT enterprise (manufacturing, services, utilities, ...) there is an understanding of the IT needs of the business supported by an enterprise architecture & a plan to implement changes to the IT infrastructure to support financial strategies (say). Is there, however, a strategy governing the infrastructure that the financial strategy must align with? If not, then, as is often the case, each new implementation is a distinct & unrelated solution to an isolated problem.
If you're an IT enterprise, then your strategies are often around the deliverables of engineering departments - product releases, product strategy to compete, etc, but are there processes within engineering that directly support those strategies? If so, how do you ensure that they align - that they have the measurable outcomes that you expect, from a business point of view, to support the objectives of the company?
The short answer is that, without some form of business architecture - an understanding of how your business functions & the inter-relatedness of all units that contribute to the company's success - then not only can you not measure the impact of strategic decisions, but it is much harder to define strategies.
Right now, you're in one of two camps - "Great, I need a business architecture - where can I get one?" or else "My company is too small for that kind of stuff". The next step is the same, regardless. If your company has strategies & expects them to be implemented, then you need a framework to ensure that they are - across the organisation. If you don't have a framework, then your strategies are written in the sand & you hope that you're above the high tide mark.
I'm not going to say what framework you need, or even whether it needs to be a formal one, but without an approach to your IT/engineering departments that incorporates decision making into company strategy, you have an unmitigated board-level risk to deal with.
Sunday, August 16, 2015
Best of Bleed
Some of the buzzwords that float around when you talk about technology or process improvement are getting dated. I can recall hearing "best of breed" close to twenty year ago. I heard "bleeding edge" not long after. If they were around before then, I must have been ignoring them as a bad joke. Things have come full circle.
Still, how else do we describe the particular nuance of meaning that those two phrases in particular encapsulate?
When someone says that they want to use a "best of breed" technology or methodology, they're not being specific - which always irked me - but they're committing to discovering what works for that particular scenario. For example, if you're starting a whole new project with little more than an idea of the functionality you want to offer (not how to provide it), then there is no definitive answer to the question "what is the best of breed"? At a high level, you might go down the dot-net path, or be open source, or somewhere in between. At a low level you have a myriad languages & frameworks to choose from that are very good at solving specific problems.
There is no one right answer. That's the point of saying something as unhelpful as "best of breed" - as long as you are actually intending to research a good solution (hopefully the best) for the problem at hand. You have to take advantage of other people's experiences to determine what is right for you. That takes effort in itself. Making the choice is not just "picking the low hanging fruit" (another of my pet hates).
It's usually an executive who likes to use "bleeding edge", meaning that they're not just at the forefront, but that they're ahead of it. A similar phrase is "ahead of the wave", although this latter doesn't have anywhere near the impact of the unspoken side-effect of the bleeding edge, which is that it's fundamentally dangerous, & someone can get hurt.
I suspect that few people who promote being on the bleeding edge think of the risks, but I would like to believe that those who are taking those challenges on - implementing new processes & using new technologies - know very well that failure is not an option. When people walk that fine line that leads to outpacing competitors & getting a business advantage out of doing things before anyone else, they're not trail-blazing with the expectation that others will follow, but ploughing ahead with the hope that no-one is following too close behind, & that they can find a way through the difficulties that no-one has faced before.
If you want to be treated seriously, then you have to be a person of your words. When you use "best of breed", you imply a knowledge of the problem space that supports process & technology choices that can be backed up by results. When you live on the "bleeding edge", you are promising risk of failure. You are promising unknown outcomes.
I'm not convinced that anyone is giving a guarantee of success in the former case, or setting up an expectation of failure in the latter.
Still, how else do we describe the particular nuance of meaning that those two phrases in particular encapsulate?
When someone says that they want to use a "best of breed" technology or methodology, they're not being specific - which always irked me - but they're committing to discovering what works for that particular scenario. For example, if you're starting a whole new project with little more than an idea of the functionality you want to offer (not how to provide it), then there is no definitive answer to the question "what is the best of breed"? At a high level, you might go down the dot-net path, or be open source, or somewhere in between. At a low level you have a myriad languages & frameworks to choose from that are very good at solving specific problems.
There is no one right answer. That's the point of saying something as unhelpful as "best of breed" - as long as you are actually intending to research a good solution (hopefully the best) for the problem at hand. You have to take advantage of other people's experiences to determine what is right for you. That takes effort in itself. Making the choice is not just "picking the low hanging fruit" (another of my pet hates).
It's usually an executive who likes to use "bleeding edge", meaning that they're not just at the forefront, but that they're ahead of it. A similar phrase is "ahead of the wave", although this latter doesn't have anywhere near the impact of the unspoken side-effect of the bleeding edge, which is that it's fundamentally dangerous, & someone can get hurt.
I suspect that few people who promote being on the bleeding edge think of the risks, but I would like to believe that those who are taking those challenges on - implementing new processes & using new technologies - know very well that failure is not an option. When people walk that fine line that leads to outpacing competitors & getting a business advantage out of doing things before anyone else, they're not trail-blazing with the expectation that others will follow, but ploughing ahead with the hope that no-one is following too close behind, & that they can find a way through the difficulties that no-one has faced before.
If you want to be treated seriously, then you have to be a person of your words. When you use "best of breed", you imply a knowledge of the problem space that supports process & technology choices that can be backed up by results. When you live on the "bleeding edge", you are promising risk of failure. You are promising unknown outcomes.
I'm not convinced that anyone is giving a guarantee of success in the former case, or setting up an expectation of failure in the latter.
Saturday, May 30, 2015
Getting Out of a Meeting
I was horrified to see a post on LinkedIn - "How to Get Out of Unnecessary Meetings". I might have been more horrified over who liked the post, but it got me thinking before I could start reading.
Regardless, don't try to get out of any meeting, necessary or otherwise - try to get SOMETHING out of every meeting. If you go into a meeting (or worse, every meeting) with the attitude "I wish I wasn't here", then you may as well not be, because you have no intention of contributing or listening.
If you go into a meeting with an open mind & a question in your heart "what can I get out of this?", then you will always find something. At the least, you will walk away thinking "if I have to organise a meeting with those people, I need a strong agenda to keep people on track & awake", or "the next time that person organises, I'm going to ask if they'd like me to chair the meeting".
Even a "necessary" meeting should not end with "I'm glad that's done with", because there should be a review in your head. Did you achieve what was necessary today? Can you get more done next time? Did people listen to you? Did you listen to everyone fairly? Who should have been there who could contribute? Who didn't need to be there? How can you better serve those people with minutes?
There is no such thing as a perfect meeting, any more than there is a meeting from which you can get nothing at all. It always comes down to the mind-set & the frame of mind (which are two very different things) - you have to want to get something out of every meeting, & you have to practice doing it.
Meetings don't even have to be that formal business context with a client or as part of a process. A good manager has a chat with team members with an agenda at least in their mind (all managers' time is precious), so the employee should have an agenda as well - use the opportunity to bring things to the fore. A one-on-one meeting is rarely a one-way conversation - even the most intense kind, disciplinary issues, are an opportunity for the employee to explain themselves before the manager has to escalate to a broader audience.
Anyone whose professional career is built around networking - consultants & salespeople, in particular - know the importance of having something in mind every time they meet with someone or get an unexpected opportunity to meet with someone. It's a not-exactly-hidden agenda that ensures that they get something out of every conversation, every greeting - even if it's only "remember me later when I might want to discuss an opportunity".
There, of course, is the crux of getting something out of a meeting. Everyone who attends the meeting with you will remember you. It's your chance to shine, to show what you can contribute to the project or the company, & how you can be looked upon as a team player.
It's your choice to take something away from every meeting for your benefit, but only through your efforts will others take something away from the meeting to your benefit.
Regardless, don't try to get out of any meeting, necessary or otherwise - try to get SOMETHING out of every meeting. If you go into a meeting (or worse, every meeting) with the attitude "I wish I wasn't here", then you may as well not be, because you have no intention of contributing or listening.
If you go into a meeting with an open mind & a question in your heart "what can I get out of this?", then you will always find something. At the least, you will walk away thinking "if I have to organise a meeting with those people, I need a strong agenda to keep people on track & awake", or "the next time that person organises, I'm going to ask if they'd like me to chair the meeting".
Even a "necessary" meeting should not end with "I'm glad that's done with", because there should be a review in your head. Did you achieve what was necessary today? Can you get more done next time? Did people listen to you? Did you listen to everyone fairly? Who should have been there who could contribute? Who didn't need to be there? How can you better serve those people with minutes?
There is no such thing as a perfect meeting, any more than there is a meeting from which you can get nothing at all. It always comes down to the mind-set & the frame of mind (which are two very different things) - you have to want to get something out of every meeting, & you have to practice doing it.
Meetings don't even have to be that formal business context with a client or as part of a process. A good manager has a chat with team members with an agenda at least in their mind (all managers' time is precious), so the employee should have an agenda as well - use the opportunity to bring things to the fore. A one-on-one meeting is rarely a one-way conversation - even the most intense kind, disciplinary issues, are an opportunity for the employee to explain themselves before the manager has to escalate to a broader audience.
Anyone whose professional career is built around networking - consultants & salespeople, in particular - know the importance of having something in mind every time they meet with someone or get an unexpected opportunity to meet with someone. It's a not-exactly-hidden agenda that ensures that they get something out of every conversation, every greeting - even if it's only "remember me later when I might want to discuss an opportunity".
There, of course, is the crux of getting something out of a meeting. Everyone who attends the meeting with you will remember you. It's your chance to shine, to show what you can contribute to the project or the company, & how you can be looked upon as a team player.
It's your choice to take something away from every meeting for your benefit, but only through your efforts will others take something away from the meeting to your benefit.
Saturday, April 4, 2015
Bring Back the Boffins
I was at a party recently when someone mentioned that in his transition from a technical role to management, it worried him that the relationship between business units & technical teams was often fractious & showed a lack of understanding. I was quite dismissive at first, suggesting that the old model of client-server approaches to IT activities was getting rather dated; but he assured me that it was commonplace for IT departments to be under-valued & generally less than ideal places to work in as a result.
I've worked predominantly in IT companies, where IT people form a large portion of the staff & are usually treated quite well, but even I had to admit that there are instances where an HR person or marketing/sales, for example, will look down on the engineers who produce the product or service on which the company was built. How strange.
Why?
One of the reasons is pure jealousy. HR people are generally clever enough (IQ) to understand people, as well as personable enough (EQ) to be effective. IT people are too often smarter (IQ) & oblivious to networking & communications skills (EQ) outside of their technical circles. There's an obvious clash. HR people work on the same level as sales people. They don't 'get' technical people, & sometimes are intimidated by both that failure & the realisation that they're not in the right sphere to be an effective communicator - they don't speak the same language. I used to work with a psychologist who referred to technical people as aliens. It actually made her a more effective communicator because of it.
I've been selective in my career, & worked in predominantly tech companies, & even when I haven't done, I've been in consulting where those tech skills are still the service that the company is selling (along with co-workers accounting skills, etc). That's essentially no different - the individuals' talents are the core of the success of the business. In effect, I work in departments of boffins - the people who solve a business' problems.
In many enterprises whose core business is, say, finance, IT is considered a service that supports the core business. These are very large, diverse, companies. Their IT people don't seem to directly contribute to the company's bottom line - they're often seen as a cost centre! Yet, the staff in IT departments are the same kind of people who staff tech companies.
These are definitely the staff that corporate HR will pigeon-hole as uncommunicative, difficult to deal with - perhaps even arrogant. As I said, these are the same technical people, so they're as likely to be at least as smart (IQ) as HR people. In a large corporation, though, the HR people are likely to be (or believe themselves to be) well above average in IQ across the staff.
Conflict.
Worse, not only are the IT people not directly contributing to the company's core business, but the new, exciting bits of product that do get touted as breakthroughs in the way that the business is conducted come from external consultants - those companies whose core business is their employees' skills. The IT staff are considered second rate - obviously not as clever as the consultants. Generally, this is just not true.
It's taken me quite a long page to describe the problem. At least I do have a solution. In successful tech companies, the engineers who come up with the ideas & implement the product or service are often treated by management as aliens - can't be understood, don't try - but as aliens who you have to respect if you don't want to be hit by a ray gun.
I prefer to think of IT people as scientists - the boffins who solve the company's problems. They are the ones that management turns to when the business has a hiccough. More importantly, large enterprises need to have their boffins in house, rather than simply have an IT service that can be out-sourced with the stroke of a budget pen.
If you don't have your own boffins, then your company's problems won't be solved - the technical issues, the business issues, the future products & services, & the staff happiness level.
I've worked predominantly in IT companies, where IT people form a large portion of the staff & are usually treated quite well, but even I had to admit that there are instances where an HR person or marketing/sales, for example, will look down on the engineers who produce the product or service on which the company was built. How strange.
Why?
One of the reasons is pure jealousy. HR people are generally clever enough (IQ) to understand people, as well as personable enough (EQ) to be effective. IT people are too often smarter (IQ) & oblivious to networking & communications skills (EQ) outside of their technical circles. There's an obvious clash. HR people work on the same level as sales people. They don't 'get' technical people, & sometimes are intimidated by both that failure & the realisation that they're not in the right sphere to be an effective communicator - they don't speak the same language. I used to work with a psychologist who referred to technical people as aliens. It actually made her a more effective communicator because of it.
I've been selective in my career, & worked in predominantly tech companies, & even when I haven't done, I've been in consulting where those tech skills are still the service that the company is selling (along with co-workers accounting skills, etc). That's essentially no different - the individuals' talents are the core of the success of the business. In effect, I work in departments of boffins - the people who solve a business' problems.
In many enterprises whose core business is, say, finance, IT is considered a service that supports the core business. These are very large, diverse, companies. Their IT people don't seem to directly contribute to the company's bottom line - they're often seen as a cost centre! Yet, the staff in IT departments are the same kind of people who staff tech companies.
These are definitely the staff that corporate HR will pigeon-hole as uncommunicative, difficult to deal with - perhaps even arrogant. As I said, these are the same technical people, so they're as likely to be at least as smart (IQ) as HR people. In a large corporation, though, the HR people are likely to be (or believe themselves to be) well above average in IQ across the staff.
Conflict.
Worse, not only are the IT people not directly contributing to the company's core business, but the new, exciting bits of product that do get touted as breakthroughs in the way that the business is conducted come from external consultants - those companies whose core business is their employees' skills. The IT staff are considered second rate - obviously not as clever as the consultants. Generally, this is just not true.
It's taken me quite a long page to describe the problem. At least I do have a solution. In successful tech companies, the engineers who come up with the ideas & implement the product or service are often treated by management as aliens - can't be understood, don't try - but as aliens who you have to respect if you don't want to be hit by a ray gun.
I prefer to think of IT people as scientists - the boffins who solve the company's problems. They are the ones that management turns to when the business has a hiccough. More importantly, large enterprises need to have their boffins in house, rather than simply have an IT service that can be out-sourced with the stroke of a budget pen.
If you don't have your own boffins, then your company's problems won't be solved - the technical issues, the business issues, the future products & services, & the staff happiness level.
Friday, March 13, 2015
Doing it Quickly Takes Longer
It's an irresistible expression - we don't have time to do it properly, so just do it quickly. Leaving aside the word 'just', which I dislike, I want you to cast your mind back & think of a time when "doing it quickly" actually was quick.
In the majority of cases, it takes longer to do things quickly. That's simple history, if you go through your catalogue of past failures. In fact, given that half the time any project that is not rushed is done on or under time, it would certainly sound as if it's much more likely that a project that isn't "done quickly" will be.
This is not counter-intuitive. Here's why.
So, what do we do about it - as managers or project managers?
If you have a time constraint, then invest more resources with the expectation that no more effort will be delivered. That's a bargain where faster time needs more effort for the same output. It's a simple equation. However, I don't mean putting more people on the task, simply more people on the project. Those people have the job of ensuring that the work gets done, & nothing more.
A manager's role, for example, would be to stand guard at the developers' desks & ensure that the people who need to be informed of progress get their regular updates only from the manager, & with expectations set by the manager. Those doing the work can then get on with the task knowing that they have a schedule of reporting to only the manager once a day (or once an hour), & no more to distract them than that.
Odd bodies added to the project are there as assistants - to get coffee, collect printouts, do research, run tests, chase down experts that need to be consulted (possibly even liaise with them) - but their contribution to the deliverables is effectively zero. That's a tough call for a manager, & it's a big ask for a professional to put their ego aside & simply be at the beck & call of a peer.
That is why it is so hard to change the way that we "do things quickly". There are a lot of bad practices & ingrained habits that we have to throw away. But it will be worth it. Each time you look at how you did something quickly last time, recognise the mistakes, correct them, & get better at it - become more reliable in your "quick" tasks through creating a repeatable process for dealing with emergencies.
In the majority of cases, it takes longer to do things quickly. That's simple history, if you go through your catalogue of past failures. In fact, given that half the time any project that is not rushed is done on or under time, it would certainly sound as if it's much more likely that a project that isn't "done quickly" will be.
This is not counter-intuitive. Here's why.
- Pressure. The reason people want things done quickly is because there is a time pressure. If you apply pressure to something it is far more likely to explode.
- Corner cutting/risk taking. The first thing that "doing something quickly" doesn't do is follow all of the good processes that are supposed to give a higher likelihood of success.
- Monitoring. Everyone is under pressure, including management, to ensure that the project completes. Given the tight deadlines, everyone (at once) tries to find out what's going on so that they prove that they're on top of the problem, thus distracting those doing the work.
- Bad estimates. Most people, if rushed for an estimate & told that a job needs to be "done quickly" will automatically underestimate it. It's a part of human nature, a part of professional pride, & it's the way such things have always been done.
So, what do we do about it - as managers or project managers?
If you have a time constraint, then invest more resources with the expectation that no more effort will be delivered. That's a bargain where faster time needs more effort for the same output. It's a simple equation. However, I don't mean putting more people on the task, simply more people on the project. Those people have the job of ensuring that the work gets done, & nothing more.
A manager's role, for example, would be to stand guard at the developers' desks & ensure that the people who need to be informed of progress get their regular updates only from the manager, & with expectations set by the manager. Those doing the work can then get on with the task knowing that they have a schedule of reporting to only the manager once a day (or once an hour), & no more to distract them than that.
Odd bodies added to the project are there as assistants - to get coffee, collect printouts, do research, run tests, chase down experts that need to be consulted (possibly even liaise with them) - but their contribution to the deliverables is effectively zero. That's a tough call for a manager, & it's a big ask for a professional to put their ego aside & simply be at the beck & call of a peer.
That is why it is so hard to change the way that we "do things quickly". There are a lot of bad practices & ingrained habits that we have to throw away. But it will be worth it. Each time you look at how you did something quickly last time, recognise the mistakes, correct them, & get better at it - become more reliable in your "quick" tasks through creating a repeatable process for dealing with emergencies.
Subscribe to:
Posts (Atom)