Do you dread meetings? Does it feel like your whole day gets sucked into a vacuum of unproductive chaos? Do you HAVE to invite attendees that argue, side track, monopolize or drone? Well as a manager it is up to you to correct this (even if it is your boss!)
I've certainly been part of the above scenarios. There were times when I would call a meeting to discuss a feature set and I knew it would turn into a technical design meeting. This was so frustrating. I had a reason to gather the team together to discuss the new features, tech talk about how to do it wasn't part of my agenda - it would stall the march to progress. Did you catch the key? agenda
How many times does someone take the time to prepare an agenda? It doesn't have to win a Pulitzer Prize, it just needs to be done. The agenda needs to explain what this meeting is about. I've been asked ad-hoc to attend a "quick meeting". These "quick meetings" go on and on and little headway is ever made without a plan. I started asking the person requesting my time to send me the topic and a break down in email. I'd print it out and bring it with me. All I can say is that right away a psychological impression was made by my just putting the "agenda" in front of me for all to see. When things started to go off track I would pick it up and make a big scrutinizing face while I "looked" for the topic that was being discussed. If you stop reading right here, then you are way farther ahead than most!
Aside from preparing an agenda (remember, doesn't have to win a literary award, but effort is always appreciated) is timekeeping. Think back to when you were last networking with someone who could provide a job or service to you. You may have asked for 10 or 20 minutes of their time and then at the end of that you said "thank you, I want to respect your other commitments and I see our time is up" (what a terrific impression). Well, why not have that respect for everyone in the meeting room? I want to hear "we love Brian's meetings!". Well, if you schedule an hour meeting make sure it is an accurate estimate. It is like estimating development work. You've already set the meetings topic and broken it down into bullets, so before the meeting invite is sent out, assign time to each section. No guessing how long to schedule anymore. When folks see times on the agenda they will immediately understand your intention to respect their time and everyone else's. Also it sets you up for some easy phrases that'll keep you on track!
So, we have prepared an agenda that includes time limits for each section. We have added up the time and sent a meeting request for the necessary amount. Our attendees have read the agenda and feel a respect for your sense of purpose. Now you have gathered at the appointed time. Well, if you needed the projector set up or white board cleaned YOU SHOWED UP EARLY! After everyone sits down reiterate that you have an agenda. It can be as easy as "Thank you all for showing attending. I want to get started right away because I know how busy you all are." Then lay out the topic for the meeting (it should be on the agenda for 30 seconds). "I only gave myself less than a minute to set the stage, so here is why we're here...". Your attendees now know that you mean business. If things start to go off topic throw in a "I knew you were going to find some interesting discussion points that aren't on the agenda. I've made a note and will schedule a follow-up to go into that, but we've only got 5 minutes left on this bullet, so I have to bring it back in". Come up with your own or share them as a comment to this post, I'd love to hear them.
Finally, you have to set a culture of efficiency and respect. Make it clear that everyone is to show up on-time. All attendees are expected to review the agenda and any attachments before hand. HOLD ON: that last one means that the meeting creator has to give busy people time to review. Stop ambushing folks - they hate that! We all know that ad-hoc meetings are necessary, but even brainstorming sessions can be structured read about these guys: http://www.ideo.com/ They've made it a science
This is my suggestion. A) agenda B) time limits C) respectful redirecting D) cultural expectations. Like I said, easy.
Good luck and let me know,
Brian
http://brianleblanc.net
Monday, October 4, 2010
Friday, October 1, 2010
Successful Staffing
There is a lot that I can say about staffing a startup technology company. I'm finding it difficult to narrow it down to the short few paragraphs that I'll present here in this blog post. Let me put it this way: technical ability is not the only factor that goes into the equation.
I am energized in a startup environment. The intense atmosphere charges me up - every second of everyday is filled with excitement. My team and I are required to put forth 100%. We think on our feet, design for anticipated feedback, create and recreate processes that enhance our efficiency and so much more. This workday can be exhilarating to the right person just as it can be pain to others. To create a vibrant team that is capable of meeting the significant challenges that face a startup tech company I always look further than technical skills.
Someone with an Axe to Grind or Something to Prove or who is just plain HUNGRY is a good place to start. I like to find candidates who are excited that they will get to take on so much more responsibility at a startup than they would be allowed at a larger company. So a person who feels that they can do things better and wants a chance to prove it may be ideal.
Now I am sure you can imagine that this may be creating a powder keg. Think about it, a room (usually a cheap one) filled with highly skilled techies that are striving to do great things. Well, defusing any potential explosions and channeling that energy into a positive direction that drives product creation is your job. Thats where your teambuilding skills come in. But you need the talent first - the right talent.
Cheers,
Brian
http://brianleblanc.net
I am energized in a startup environment. The intense atmosphere charges me up - every second of everyday is filled with excitement. My team and I are required to put forth 100%. We think on our feet, design for anticipated feedback, create and recreate processes that enhance our efficiency and so much more. This workday can be exhilarating to the right person just as it can be pain to others. To create a vibrant team that is capable of meeting the significant challenges that face a startup tech company I always look further than technical skills.
Someone with an Axe to Grind or Something to Prove or who is just plain HUNGRY is a good place to start. I like to find candidates who are excited that they will get to take on so much more responsibility at a startup than they would be allowed at a larger company. So a person who feels that they can do things better and wants a chance to prove it may be ideal.
Now I am sure you can imagine that this may be creating a powder keg. Think about it, a room (usually a cheap one) filled with highly skilled techies that are striving to do great things. Well, defusing any potential explosions and channeling that energy into a positive direction that drives product creation is your job. Thats where your teambuilding skills come in. But you need the talent first - the right talent.
Cheers,
Brian
http://brianleblanc.net
Wednesday, August 18, 2010
Burn the Boats!
I think many of us have heard the legend of Hernando Cortez and how he captured the amazing wealth from Mexico that had so long evaded other European conquerers. If not, you can read all about it here: http://www.tonybrownonline.com/rts/index.asp?action=page&name=16525&siteid=1421
The main thrust of the story is that if you leave an avenue of escape open to yourself than you will not fight as hard for your prize. “Make or break”; “Plunder or parish”; “Do or die”. This is the message that Cortez sent to his men when he said “Burn the boats! Because if we're going home, we're going home in their boats!”
How do you think Cortez's men felt? They were facing a challenge that no one had succeeded at before. In fact, there was overwhelming proof that they were going to fail because so many had before. They were going to succeed or die. Now, how would they have felt if they had known that the boats were offshore waiting to take them home safely? Maybe a risky battle move would not be tried? Maybe they wouldn't give 110%? I think we all get it. Cortez knew what he wanted and knew he wouldn't get it if he and his men were left a safe getaway.
How does the Cortez legend apply to startup management? It is the single-most important energy for you and your team to embody for success.
How do you get that feeling? Well, for starters, how about investing everything that you have? If you know that you face financial ruin if you fail to deliver a product to market, how will you behave? Will you stay up late? Will you forgo the upgraded TV to keep afloat a bit longer? IMPORTANT: will you be extra choosy about who you hire into your company? Lets talk about that one for a moment. If your savings depended on who you hired wouldn't you want to hire in those who would work hard like you will?
What else about those that we hire? If Cortez was the only one who couldn't get back on the boat would he have only burned his? NO WAY. He burned everybody's boat. You must create a situation where all participants feel invested and you only want those that will fight to the end. Partial ownership is one way. Ownership gives a great incentive for victory, though you still have to be careful because if someone doesn't believe in the cause they could just be there for the paycheck. Another way is separation.
Is your endeavor an effort for a larger company? Are the engineers employees of the larger company? Break the ties. Move locations. Make everyone uncomfortable. “This is our new office. It is small and dingy. This is what we are affording to stay open. If we don't hit each and every milestone with quality these doors may be locked the next time you show up for work.” Who would want to work in this atmosphere and with this kind of pressure? I do! And so do many others.
Startups are cool! We get to do things and take responsibilities that larger companies don't always allow. It is fast paced and exciting. There is an element of danger. Some people thrive on this. A lot of folks don't. Pick your crew well, inspire them with the promise of shared wealth, and BURN THE BOATS!
The main thrust of the story is that if you leave an avenue of escape open to yourself than you will not fight as hard for your prize. “Make or break”; “Plunder or parish”; “Do or die”. This is the message that Cortez sent to his men when he said “Burn the boats! Because if we're going home, we're going home in their boats!”
How do you think Cortez's men felt? They were facing a challenge that no one had succeeded at before. In fact, there was overwhelming proof that they were going to fail because so many had before. They were going to succeed or die. Now, how would they have felt if they had known that the boats were offshore waiting to take them home safely? Maybe a risky battle move would not be tried? Maybe they wouldn't give 110%? I think we all get it. Cortez knew what he wanted and knew he wouldn't get it if he and his men were left a safe getaway.
How does the Cortez legend apply to startup management? It is the single-most important energy for you and your team to embody for success.
How do you get that feeling? Well, for starters, how about investing everything that you have? If you know that you face financial ruin if you fail to deliver a product to market, how will you behave? Will you stay up late? Will you forgo the upgraded TV to keep afloat a bit longer? IMPORTANT: will you be extra choosy about who you hire into your company? Lets talk about that one for a moment. If your savings depended on who you hired wouldn't you want to hire in those who would work hard like you will?
What else about those that we hire? If Cortez was the only one who couldn't get back on the boat would he have only burned his? NO WAY. He burned everybody's boat. You must create a situation where all participants feel invested and you only want those that will fight to the end. Partial ownership is one way. Ownership gives a great incentive for victory, though you still have to be careful because if someone doesn't believe in the cause they could just be there for the paycheck. Another way is separation.
Is your endeavor an effort for a larger company? Are the engineers employees of the larger company? Break the ties. Move locations. Make everyone uncomfortable. “This is our new office. It is small and dingy. This is what we are affording to stay open. If we don't hit each and every milestone with quality these doors may be locked the next time you show up for work.” Who would want to work in this atmosphere and with this kind of pressure? I do! And so do many others.
Startups are cool! We get to do things and take responsibilities that larger companies don't always allow. It is fast paced and exciting. There is an element of danger. Some people thrive on this. A lot of folks don't. Pick your crew well, inspire them with the promise of shared wealth, and BURN THE BOATS!
Thursday, February 11, 2010
Great Expectations
These days it is difficult to ignore the benefits of offshore development. The potential cost reduction's beneficial effect on a company's profit margin warrants investigation. I am sure a lot of readers are thinking that this is old news, yet I feel that there is significant room for innovation in this model that will make it even more attractive to those who have not tapped these resources for whatever reason.
My experience is mainly with companies based in India. Over the years I have had varied success but on the whole it has been positive. Keep that in mind, because the sheer volume of teams vying for your business is more than overwhelming. They are persistent and tireless in pursuit of your projects and as you would guess, many make promises that they cannot keep. The important part is to have a plan and go into the endeavor with realistic expectations. “Too good to be true” is a sound rule here.
Some ways that you can raise your chances for success with your software project is to use the commonsense methodologies that you would use in any other instance where you are evaluating an unknown.
The first thing to do is to be specific about what you want. If you have technological constraints be clear in your solicitation that you only want to hear from companies that have significant and relevant experience. If you haven't decided on technology (say Ruby on Google App Engine vs. .NET on Azure) ask for a company that has done project work closely related to the functionality that you wish to develop/enhance. If you know both of these, ask to only hear from those that fit the bill in totality. Remember, there are so many offshore development shops that you have a very good chance of finding more than a few that will meet both criteria.
After you have found a few companies to consider, ask for pricing. This varies widely. There are larger (less risky) shops that charge more. You'll find a that with the more established company the benefit to you is the savings on infrastructure and employee services. These shops usually not only charge significantly higher rates, but they have team size quotas and require deep contractual agreements. The smaller companies usually provide the best deal financially, but you have to be on your game in the evaluation period.
When you have boiled down the competition then it is time to do exactly what you would expect, ask for demos of their work that directly relates to the functionality that you wish to build. And then ask for the contact information. Speak to the client that they built it for. Not only must your potential resource be technically apt, but they must be manageable and accountable. Ask the reference your operational questions. They must be able to produce “local” references. I have found that these references are usually very forthcoming in their critiques.
Now it is time to work on you. What do you expect?
From my experience I expect that I can enhance my chances for success by implementing a model where my trusted local team provides detailed technical documentation and that we schedule the resources ourselves. The more specific we can be about not only the look and feel, but how to implement technically the better the results. This model necessitates a local architect. However, if you were to go the 100% offshore resource model, then I would ask you to be sure to continue to provide impeccable functional specifications (painfully detailed) and insist on technical documentation back that could win a Pulitzer Prize.
This is a lot of commonsense advice. The benefit to hearing it though is that it may help to counteract the many sales pitches that a newcomer to off shoring will receive. You may be promised the world at an unbelievably low price, but to take it at face value may put you in a situation where you are disappointed and your effort is endangered. While I have provided some of the steps that will help you create a successful relationship, nothing replaces experience. Working with someone that has gone through this process before will help ensure your expectations. Not only does an experienced offshore manager enable the day-to-day, but they better understand the culture and can provide valuable contacts with trustworthy sources.
So good luck with your team setup. I am always excited about global resources and the technology that enables us to benefit our bottom line while enhancing someone else's standard of living.
Best wishes,
Brian
My experience is mainly with companies based in India. Over the years I have had varied success but on the whole it has been positive. Keep that in mind, because the sheer volume of teams vying for your business is more than overwhelming. They are persistent and tireless in pursuit of your projects and as you would guess, many make promises that they cannot keep. The important part is to have a plan and go into the endeavor with realistic expectations. “Too good to be true” is a sound rule here.
Some ways that you can raise your chances for success with your software project is to use the commonsense methodologies that you would use in any other instance where you are evaluating an unknown.
The first thing to do is to be specific about what you want. If you have technological constraints be clear in your solicitation that you only want to hear from companies that have significant and relevant experience. If you haven't decided on technology (say Ruby on Google App Engine vs. .NET on Azure) ask for a company that has done project work closely related to the functionality that you wish to develop/enhance. If you know both of these, ask to only hear from those that fit the bill in totality. Remember, there are so many offshore development shops that you have a very good chance of finding more than a few that will meet both criteria.
After you have found a few companies to consider, ask for pricing. This varies widely. There are larger (less risky) shops that charge more. You'll find a that with the more established company the benefit to you is the savings on infrastructure and employee services. These shops usually not only charge significantly higher rates, but they have team size quotas and require deep contractual agreements. The smaller companies usually provide the best deal financially, but you have to be on your game in the evaluation period.
When you have boiled down the competition then it is time to do exactly what you would expect, ask for demos of their work that directly relates to the functionality that you wish to build. And then ask for the contact information. Speak to the client that they built it for. Not only must your potential resource be technically apt, but they must be manageable and accountable. Ask the reference your operational questions. They must be able to produce “local” references. I have found that these references are usually very forthcoming in their critiques.
Now it is time to work on you. What do you expect?
From my experience I expect that I can enhance my chances for success by implementing a model where my trusted local team provides detailed technical documentation and that we schedule the resources ourselves. The more specific we can be about not only the look and feel, but how to implement technically the better the results. This model necessitates a local architect. However, if you were to go the 100% offshore resource model, then I would ask you to be sure to continue to provide impeccable functional specifications (painfully detailed) and insist on technical documentation back that could win a Pulitzer Prize.
This is a lot of commonsense advice. The benefit to hearing it though is that it may help to counteract the many sales pitches that a newcomer to off shoring will receive. You may be promised the world at an unbelievably low price, but to take it at face value may put you in a situation where you are disappointed and your effort is endangered. While I have provided some of the steps that will help you create a successful relationship, nothing replaces experience. Working with someone that has gone through this process before will help ensure your expectations. Not only does an experienced offshore manager enable the day-to-day, but they better understand the culture and can provide valuable contacts with trustworthy sources.
So good luck with your team setup. I am always excited about global resources and the technology that enables us to benefit our bottom line while enhancing someone else's standard of living.
Best wishes,
Brian
Monday, February 1, 2010
What's your group mindset?
I've been reading Mindset by Carol Dweck, Ph.D. This is her take on the psychology of success. It deals with what she calls a “fixed mindset” and a “growth mindset”. A major theme in this book is that those of us who have the growth mindset embrace challenges (and even failures) as an exciting way to learn. She explains that people who believe that they have the capacity to become more intelligent look for ways to learn new things and therefore DO become smarter. On the reverse side of this coin are those who live with a fixed mindset. Here she believes live the people who have bought into the belief that your IQ is static. They spend a lot of energy proving their worth time and again attempting to seem smart and avoiding situations where they are challenged. After reading through a good portion of this, I began to reflect back on how this applies in a startup technology company. Can an organization have a collective mindset? I say yes.
Going into a startup technology endeavor (I'll say software because that is what I do) a battle scarred vet is going to know that no matter how well the upfront planning was done, unexpected challenges loom around many corners waiting to derail even the best efforts. Now, top-notch technical specifications is one of the ways to reduce the risk and therefore the impact of these “unknowns”, but there will still be some and how the team deals responds to them builds the development culture.
Applying Dweck's theory it is plain to see that the group has the choice to view the challenges as a way to learn or as another roadblock on their way to success. What example will the team lead set? Here is my hope: that early on the manager rubs his/her hands together and says“ahhh, here is an opportunity for us to increase our knowledge base, gauge the amount of time necessary for unknowns, and prove our expertise as a team”. What I mean here is a) solve a problem once and it is solved forever if a short article up on the team wiki b) time how long it takes to resolve the issue and use that factor in development estimates going forward (keep revising this as the team gets better at it). Here is a wonderful metric for evaluating the team. c) Show off! It is a good feather in the group's cap that they were hit with undocumented technical challenges and only took x amount of time to overcome them. This approach/attitude is one of the building blocks to creating an exciting team that thrives in the often unknown technical environment of a startup.
For brevity's sake, I presented just the positive side of the argument. I think we can all see what kind of group is built with a fixed mindset. I am encouraged to reinvigorate my own attitude this week when the inevitable challenge arises. I think my phrase will be “Oh! Good, this is a cool issue to work on. Who is lucky enough to spend some cycles puzzling on this one?”
Good luck,
Brian
Going into a startup technology endeavor (I'll say software because that is what I do) a battle scarred vet is going to know that no matter how well the upfront planning was done, unexpected challenges loom around many corners waiting to derail even the best efforts. Now, top-notch technical specifications is one of the ways to reduce the risk and therefore the impact of these “unknowns”, but there will still be some and how the team deals responds to them builds the development culture.
Applying Dweck's theory it is plain to see that the group has the choice to view the challenges as a way to learn or as another roadblock on their way to success. What example will the team lead set? Here is my hope: that early on the manager rubs his/her hands together and says“ahhh, here is an opportunity for us to increase our knowledge base, gauge the amount of time necessary for unknowns, and prove our expertise as a team”. What I mean here is a) solve a problem once and it is solved forever if a short article up on the team wiki b) time how long it takes to resolve the issue and use that factor in development estimates going forward (keep revising this as the team gets better at it). Here is a wonderful metric for evaluating the team. c) Show off! It is a good feather in the group's cap that they were hit with undocumented technical challenges and only took x amount of time to overcome them. This approach/attitude is one of the building blocks to creating an exciting team that thrives in the often unknown technical environment of a startup.
For brevity's sake, I presented just the positive side of the argument. I think we can all see what kind of group is built with a fixed mindset. I am encouraged to reinvigorate my own attitude this week when the inevitable challenge arises. I think my phrase will be “Oh! Good, this is a cool issue to work on. Who is lucky enough to spend some cycles puzzling on this one?”
Good luck,
Brian
Monday, January 25, 2010
Inter-release scheduling
It takes a special person to lead a start up team. They must enjoy challenges that others may find just too frustrating for words. But it is in this daily 'point - counter point' that the true start up manager thrives. A good example of this theme is what all engineering teams face in the beginning: many high-priority feature requests and a skeleton crew of resources to implement them. Lets call this resource constraint.
Resource constraint is dealt with in many different ways. One way that can be effective is to create a hybrid development model that leverages less expensive off-shore developers to supplement your local team. I plan to talk more about this model in another note, but for now I want to focus on how to make sense of multiple development efforts being run concurrently.
Because a startup is aggressively seeking to become a self-sustainable entity, any sale is treated with the highest level of criticality. So as we methodically move forward, implementing our vision of the perfect software product, we are bombarded with requests from potential sales. To an outsider, the view of the functionality in development may seem disjointed, but we all know that these pieces must be built in quickly to generate sales. On the other hand, we have a team of developers with a variety of skills. You'll see that it really becomes a puzzle of organizing projects based on when the right resource will be available versus architectural priority (i.e. this functionality must be built in to allow that functionality).
I have found one way to achieve a smoothly running team in such an environment is to create inter-release schedules. What I mean by this is schedules that are based on functionality rather than a specific deliverable. First, break the plan up by functional requirement (imagine all of the tasks for Outlook Integration v1 grouped together, then a blank line, and then the tasks for Next Phase of Reporting). Maybe Outlook Integration will be in the next release, but Reporting is not, but having it on the schedule will allow for always making the best use of your resources time. For instance if Dev A completes a task and cannot move onto the next task in that functional area until Dev B completes some supporting tasks, then you can move them onto their part of feature development elsewhere.
I think that you can see that there is a lot more finesse to this than I am able to go into here, but there are a few of you that see the fun. To those readers (that see the fun) I want to say: realize that others see this as a frustrating chore while you see a chess game. Obviously you have to have a well thought out branching scheme in source control. You must know your developers strengths. Also you have to have built a bonded team that respects you and will take direction. Finally you must balance resource reallocation so that it does not become overly tiresome on your team. There is more, but you get the idea.
Cheers,
Brian
Resource constraint is dealt with in many different ways. One way that can be effective is to create a hybrid development model that leverages less expensive off-shore developers to supplement your local team. I plan to talk more about this model in another note, but for now I want to focus on how to make sense of multiple development efforts being run concurrently.
Because a startup is aggressively seeking to become a self-sustainable entity, any sale is treated with the highest level of criticality. So as we methodically move forward, implementing our vision of the perfect software product, we are bombarded with requests from potential sales. To an outsider, the view of the functionality in development may seem disjointed, but we all know that these pieces must be built in quickly to generate sales. On the other hand, we have a team of developers with a variety of skills. You'll see that it really becomes a puzzle of organizing projects based on when the right resource will be available versus architectural priority (i.e. this functionality must be built in to allow that functionality).
I have found one way to achieve a smoothly running team in such an environment is to create inter-release schedules. What I mean by this is schedules that are based on functionality rather than a specific deliverable. First, break the plan up by functional requirement (imagine all of the tasks for Outlook Integration v1 grouped together, then a blank line, and then the tasks for Next Phase of Reporting). Maybe Outlook Integration will be in the next release, but Reporting is not, but having it on the schedule will allow for always making the best use of your resources time. For instance if Dev A completes a task and cannot move onto the next task in that functional area until Dev B completes some supporting tasks, then you can move them onto their part of feature development elsewhere.
I think that you can see that there is a lot more finesse to this than I am able to go into here, but there are a few of you that see the fun. To those readers (that see the fun) I want to say: realize that others see this as a frustrating chore while you see a chess game. Obviously you have to have a well thought out branching scheme in source control. You must know your developers strengths. Also you have to have built a bonded team that respects you and will take direction. Finally you must balance resource reallocation so that it does not become overly tiresome on your team. There is more, but you get the idea.
Cheers,
Brian
Wednesday, January 6, 2010
The Fast & The Furious: Process
The enjoyment that I have found in effecting turn-arounds in both operational and development environments comes from bringing order to chaos. I think it is fun to take charge of something that is broken and fix it. It's about the love of putting things in order (or is it the "need" to put things in order?). This usually takes the form of establishing new and efficient processes, documenting them and then training personnel in their use. There is a lot of work that goes into the last sentence (things I didn't even hint at), but as I said it can be a lot of fun and extremely rewarding.
Working a start-up company can present some of the same challenges and opportunities for "fun", but there are also some key differences. With no established procedures to work with, there is a clean slate on which to make your informed sensible decisions. There are no bad habits to break or mysteries to be solved, it is all about understanding the goals of this new venture and then customizing a successful template that you feel best suits the situation at hand. So again we find "establishing new and efficient processes, documenting them and then training personnel on their use".
One difference in crafting a turn-around at an established company and manning a start-up is the post implementation of your plan. For a turn-around the win is not only to bring the environment to a pre-defined level of achievement, but to implement a continuous improvement plan based on metrics. The procedures that were put into place need to be made up of measurable tasks which provide the metrics necessary for ongoing improvement. This is the hard part - the constant monitoring of the machine and then making the minute adjustments that increase efficiency. In a start-up this task is 100 times more difficult.
The best laid plans of mice and men, right? The ground is never too firm at a start-up, there are just too many variables. What I call "infrastructure processes" are established, providing the stability necessary for the team to move forward. Over time however factors such as the economy, new technology, governmental policy, and input from investors will have an effect on a company's goals and therefore the processes. This effect is amplified for a start-up. Flexibility must be king if the organization is to adapt. This is a different kind of fun.
In a start-up the ground may quake beneath your feet much more frequently and with more volatility. It may not be enough to make minute changes - the whole play book can suddenly be called into question. In conceiving an initial plan, the leader's job is to not only assess the new venture's goals and vision but to then weigh the risk factors that may adversely effect their efforts. For instance, what is the probability that a key governmental policy that is critical to the business will change? With this decision analysis having been done, the best plan for the organization can be established. However, a prudent leader will then staff the new enterprise with energetic and flexible personnel that can weather the exciting and challenging tasks in this fast and furious environment.
~Brian
http://brianleblanc.net
Working a start-up company can present some of the same challenges and opportunities for "fun", but there are also some key differences. With no established procedures to work with, there is a clean slate on which to make your informed sensible decisions. There are no bad habits to break or mysteries to be solved, it is all about understanding the goals of this new venture and then customizing a successful template that you feel best suits the situation at hand. So again we find "establishing new and efficient processes, documenting them and then training personnel on their use".
One difference in crafting a turn-around at an established company and manning a start-up is the post implementation of your plan. For a turn-around the win is not only to bring the environment to a pre-defined level of achievement, but to implement a continuous improvement plan based on metrics. The procedures that were put into place need to be made up of measurable tasks which provide the metrics necessary for ongoing improvement. This is the hard part - the constant monitoring of the machine and then making the minute adjustments that increase efficiency. In a start-up this task is 100 times more difficult.
The best laid plans of mice and men, right? The ground is never too firm at a start-up, there are just too many variables. What I call "infrastructure processes" are established, providing the stability necessary for the team to move forward. Over time however factors such as the economy, new technology, governmental policy, and input from investors will have an effect on a company's goals and therefore the processes. This effect is amplified for a start-up. Flexibility must be king if the organization is to adapt. This is a different kind of fun.
In a start-up the ground may quake beneath your feet much more frequently and with more volatility. It may not be enough to make minute changes - the whole play book can suddenly be called into question. In conceiving an initial plan, the leader's job is to not only assess the new venture's goals and vision but to then weigh the risk factors that may adversely effect their efforts. For instance, what is the probability that a key governmental policy that is critical to the business will change? With this decision analysis having been done, the best plan for the organization can be established. However, a prudent leader will then staff the new enterprise with energetic and flexible personnel that can weather the exciting and challenging tasks in this fast and furious environment.
~Brian
http://brianleblanc.net
Subscribe to:
Posts (Atom)