This is an ongoing question from the moment that you have a product and even a prospective customer. Real-time requirements for assistance, demos, features and bugfixing are common diversions for many engineering groups. So how do you handle this natural competition for resources?
The first thing you need is a roadmap. Without clear plans and goals you won't even know what you are not doing. Time can slip by easily in fire-fighting mode and along with it market opportunities.
The next thing you need is a budget. You need to legitimize the time spent on diversions from the roadmap. Do not expect your developers to handle a full development load along with a second development load for bugfixing. Another key to successfully managing resource competition is to firewall resources for new development (see Christensen's 1997 book The Innovator's Dilemma).
The next thing you need is some process. Decent schedules which represent all of the activities engineering is responsible for is a must. If new opportunities arise, do not assume the team can just lump more work on. I like schedules to be aggressive but accomplishable -- where the key word is accomplishable. Put a process in place that allows for change. If a new feature is needed, will you fund it with new resources, re-target resources working on some of projects, etc. ? Outside influence can begin to look like a fire-fight. Changing directions too often will be inefficient and depress developers.
Finally you need leadership. Understand your team's capacity. Understand your company's financial and competitive situation. Aggressive but accomplishable.
More later ...
10/24/2005
Live to work or work to live?
This is a question that many people ask implicitly or explicitly. It is a value that changes during a lifetime. Teenagers might feel work minimally to live only to become twenty-something work-aholics to become burned-out forty-somethings trying to reconnect with their families. The lucky among us find balance. But let's go back to the question, what should you do? How should you think about work?
I have the pleasure of being the dad to a wonderful teenage girl who is starting to be interested in the inevitability of work. She wants to earn enough to do stuff. She doesn't feel like she needs to live my lifestyle (yet:-). She is getting pressure from her school to think about careers. So I will lean on what I tell her as I write this entry.
I tell her she has to do two things: find something she enjoys doing a lot and be passionate about and find something that will pay the bills for the lifestyle she chooses.
In reading the first item, I think the keyword is passion. When I started working a colleague of mine said "If you are not willing to put in more than eight hours in a job, why are you willing to put in eight?" The upshot of his statement was that when we work we invest our most alert and most valuable hours of our day and we should use those hours doing something we love and are passionate about. I agree with him.
If you only work to meet your financial needs, you will be miserable. Sometimes we have to do things we would otherwise choose not to do. You need to understand this aspect of your life. However, I suspect that most of us can figure out how to do something we are passionate about and still pay the bills.
When I hire people, I look for people who have that passion. I do not want someone just paying the bills or putting in time.
So how do I answer this for myself? I live to be passionate and excited about all aspects of my life and today that includes work.
More later ...
I have the pleasure of being the dad to a wonderful teenage girl who is starting to be interested in the inevitability of work. She wants to earn enough to do stuff. She doesn't feel like she needs to live my lifestyle (yet:-). She is getting pressure from her school to think about careers. So I will lean on what I tell her as I write this entry.
I tell her she has to do two things: find something she enjoys doing a lot and be passionate about and find something that will pay the bills for the lifestyle she chooses.
In reading the first item, I think the keyword is passion. When I started working a colleague of mine said "If you are not willing to put in more than eight hours in a job, why are you willing to put in eight?" The upshot of his statement was that when we work we invest our most alert and most valuable hours of our day and we should use those hours doing something we love and are passionate about. I agree with him.
If you only work to meet your financial needs, you will be miserable. Sometimes we have to do things we would otherwise choose not to do. You need to understand this aspect of your life. However, I suspect that most of us can figure out how to do something we are passionate about and still pay the bills.
When I hire people, I look for people who have that passion. I do not want someone just paying the bills or putting in time.
So how do I answer this for myself? I live to be passionate and excited about all aspects of my life and today that includes work.
More later ...
10/19/2005
Why write a book?
Today I formally launched my book 100 Questions to Ask Your Software Organization. The official press release went out. The book is available for sale. But why write a book? What was I trying to accomplish?
I had been writing some form of the book in my head for 9 years. When I sat down to write the book, it popped out of me. I wanted to write a practical, easy-to-read, scalable guide for software managers and executives who have software organizations reporting to them.
As I walked into organizations as a full time employee or as a consultant, I was applying some of the same methods time and time again. I wanted a guide to remind myself about those methods. I wanted a concise mechanism to help communicate with the team about my methods and my intent. I wanted a basis for discussion about better software management.
I talked to a lot of people along the way. One of those people was a venture capitalist who said he needed a better way to understand and evaluate software organizations in his portfolio. With that comment, I adopted the question format. I have been told by readers that it helps the momentum of the book. The questions lead the reader in the right direction and the words that follow strive to help the reader understand what is important to consider as they develop answers for themselves.
There is a crisis in this industry. Late and poor quality software are the norm and not the exception. Disgruntled and burnt-out employees are almost expected. Customers assume they cannot trust vendors based on real historical evidence.
We can do better. It is not rocket science.
Realistic budgets and roadmaps. Clear roles and responsibilities. Effective and efficient processes.
Leadership.
With this book I challenge you all to start a new dialogue. To begin anew. To be better.
More later ...
I had been writing some form of the book in my head for 9 years. When I sat down to write the book, it popped out of me. I wanted to write a practical, easy-to-read, scalable guide for software managers and executives who have software organizations reporting to them.
As I walked into organizations as a full time employee or as a consultant, I was applying some of the same methods time and time again. I wanted a guide to remind myself about those methods. I wanted a concise mechanism to help communicate with the team about my methods and my intent. I wanted a basis for discussion about better software management.
I talked to a lot of people along the way. One of those people was a venture capitalist who said he needed a better way to understand and evaluate software organizations in his portfolio. With that comment, I adopted the question format. I have been told by readers that it helps the momentum of the book. The questions lead the reader in the right direction and the words that follow strive to help the reader understand what is important to consider as they develop answers for themselves.
There is a crisis in this industry. Late and poor quality software are the norm and not the exception. Disgruntled and burnt-out employees are almost expected. Customers assume they cannot trust vendors based on real historical evidence.
We can do better. It is not rocket science.
Realistic budgets and roadmaps. Clear roles and responsibilities. Effective and efficient processes.
Leadership.
With this book I challenge you all to start a new dialogue. To begin anew. To be better.
More later ...
10/07/2005
What does "Done" mean?
According to Webster, done is the past participle of do. According to Webster, do's definition includes produce, perform, execute, commit and carry-out. The problem with these definitions is that they do not speak to the agreement required by multiple parties as to the contextual semantics of the state of being done. In other words, when do all parties agree a product is produced or a task carried-out? This is a topic worth exploring because it causes angst, misunderstandings, delays in products, missing product quality, etc.
I recall a start-up I worked in a number of years back that had a fairly large release to accomplish. The release included new hardware and new software from the firmware through GUI. I was brought in to run the software group and more explicitly to execute. We had all of the typical problems: top-down dates, too much work for the number of resources, poorly defined features, unmade critical decisions. I worked on all of these with the team. I helped force clear and complete decisions. I helped set expectations about what really could be accomplished and divided the work into required and second tier. I helped the team make real schedules. When we got to the code complete milestone, my engineers said they were complete but we were not complete. Why did that happen?
I made the mistake that everyone shared the same concept of the word "done". To me, done, was, well, done! My engineers and even some of my managers thought that close was good enough. Of course this caused all hell to break loose. The QA folks could not test, the product management folks screamed publicly, and the engineers felt put-upon.
So now I take the time at team meeting to express my definition of done. When a project starts, I look each developer in the eye and ask them if they stand by their schedules. I require specs that can be compared with requirements documents so there can be no misunderstandings. I require developers write reproducible unit tests that can verify tasks do what they say they do before check-in.
Were my engineers bad or unique? No to both of those questions. Many engineers are not taught the meaning of the word "done" or worse yet, they are castigated for it. This is the new millennium and there are some basics when it comes to development. Take the time to agree with your team as to when they are done ...
More later ...
I recall a start-up I worked in a number of years back that had a fairly large release to accomplish. The release included new hardware and new software from the firmware through GUI. I was brought in to run the software group and more explicitly to execute. We had all of the typical problems: top-down dates, too much work for the number of resources, poorly defined features, unmade critical decisions. I worked on all of these with the team. I helped force clear and complete decisions. I helped set expectations about what really could be accomplished and divided the work into required and second tier. I helped the team make real schedules. When we got to the code complete milestone, my engineers said they were complete but we were not complete. Why did that happen?
I made the mistake that everyone shared the same concept of the word "done". To me, done, was, well, done! My engineers and even some of my managers thought that close was good enough. Of course this caused all hell to break loose. The QA folks could not test, the product management folks screamed publicly, and the engineers felt put-upon.
So now I take the time at team meeting to express my definition of done. When a project starts, I look each developer in the eye and ask them if they stand by their schedules. I require specs that can be compared with requirements documents so there can be no misunderstandings. I require developers write reproducible unit tests that can verify tasks do what they say they do before check-in.
Were my engineers bad or unique? No to both of those questions. Many engineers are not taught the meaning of the word "done" or worse yet, they are castigated for it. This is the new millennium and there are some basics when it comes to development. Take the time to agree with your team as to when they are done ...
More later ...
Subscribe to:
Posts (Atom)