4 ms·

I do it well, but only after I completely understand the problem. For instance, I wrote out a series of design documents, then gathered buy in for management to

I do it well, but only after I completely understand the problem. For instance, I wrote out a series of design documents, then gathered buy in for management to start hiring. I told them that this will take 2 years to complete, but we can start realizing value in the first six months. Every timeframe was hit without crunch, and everything landed roughly on schedule. The problem is that most people I've met dont really understand what they are actually doing and/or have the leadership to grow people to achieve. It is not trivial in the least and requires a great deal of lead time to even understand the problem(s). This field is at its infancy, and I dont yet know if my insights can be replicated yet. I'm thinking of writing a book where I illustrate thought exercises and career challenges that help people grow from junior to senior principal, but it is proving difficult.

jdc 7y ago
How long does it take to understand the problem and write design documents?
- mathgladiator 7y ago
  3 to 6 months... maybe longer. The key is to focus that time towards collecting data to help sell to stakeholders.
- commandlinefan 7y ago
  According to every project manager/“agile coach” I’ve ever worked with, that would be part of a one-hour “grooming meeting” and if it takes longer than that, you must just be an incompetent developer, in need of more “coaching”.
generatorguy 7y ago
Isn’t The hard part understanding the problem and writing the design documents? That is the task which takes the unknown amount of time. Once the roadmap is in place and people are assigned to build the things that have been designed the problems that occur are much more concrete. Unless there is some oversight or omission in the design, change in the requirements. Etc. How long was the discovery and design document phase on the 2 year project?
- AmericanChopper 7y ago
  For every project I work on, I make sure I understand the problem, define the requirements, design the solution, and validate any necessary design patterns before I begin planning the implementation. How long that takes depends on the scope of the project, but I have never seen a project save time by skipping that bit. I also end up being pretty accurate with my time estimates.
  - tsimionescu 7y ago
    What I have seen several times with that approach is a wonderful plan that needs to get scrapped about half-way through when the requirements suddenly change, for various market-related reasons. Some sketch of the end-design is always important, thinking about major components and future evolution, but a detailed plan has never been worth it in my line of work.
    - AmericanChopper 7y ago
      If you’re making radical changes to your design half way through, then you didn’t understand the problem you were trying to solve to begin with, and possibly didn’t define your requirements properly either. If small changes to your requirements mean you need to do significant redesign, then you didn’t design your solution properly. The most generous way to view what you described is that you’ve had to cancel your project half way through and start a new one. There’s nothing you can do to make business decisions like that work smoothly. In my experience though, a more likely cause of what you’ve described, is that the project was just planned poorly to begin with.
      - tsimionescu 7y ago
        The problem I was alluding to is exactly one of requirements - requirements aren't always exact, and they may change in unexpected ways as time goes on. In my experience, this is relatively common when building products that have a long time to market: since there are no hard requirements to begin with, just guesses on what features would be useful to have, it is easy for different marketing and product people to have different opinions and change their minds on what is or isn't an important feature.
chrisweekly 7y ago
A 2-year horizon -- even for massive, strategically sound projects -- is a non-starter, simply untenable in virtually every situation I've encountered in my 21-yr career in software dev and mgmt and consulting. Not saying you're wrong to think and advise in those terms, just that the opportunity to do so is exceedingly rare. Big public companies tend to be overly constrained by quarterly myopia, and startups usually don't have runway to attempt to plan that far out. Personally, I once endured a project being shelved after 15+ months of solid, productive effort. I've also been the catalyst, at least twice, for adoption of paradigm shifts that ultimately spanned ~2yr timeframes (one was performance as a first-class citizen, and another was incorporating RWD (responsive web design) into a large company's MO. These successful cross-cutting / interdepartmental changes took time, but I don't think either of them could have happened if they'd ever been pitched up front as multi-year projects. Maybe you've just been luckier finding far-sighted decision-makers. (If I seem bitter, I'm not. Just sharing my lived experience.)
- mathgladiator 7y ago
  I think it depends on scale and the inertia involved, and my original point was that accurate estimation is possible. There are many other challenges as you point out. I am currently on year two of a five year project. The key (and part of the essential difficulty) is finding quarterly or six month valuable deliverables that help ease anxiety of everyone involved. It is not easy, but it is possible. While all this is going on, I'm also working on a design document for a potential 10 year project. I doubt that I will pull this one off since I'm having difficulty finding those quarterly deliverables, but I'll keep grinding away.
  - chrisweekly 7y ago
    Right on. Good luck!

jdc 7y ago

How long does it take to understand the problem and write design documents?

mathgladiator 7y ago
3 to 6 months... maybe longer. The key is to focus that time towards collecting data to help sell to stakeholders.
commandlinefan 7y ago
According to every project manager/“agile coach” I’ve ever worked with, that would be part of a one-hour “grooming meeting” and if it takes longer than that, you must just be an incompetent developer, in need of more “coaching”.

generatorguy 7y ago

Isn’t The hard part understanding the problem and writing the design documents? That is the task which takes the unknown amount of time. Once the roadmap is in place and people are assigned to build the things that have been designed the problems that occur are much more concrete. Unless there is some oversight or omission in the design, change in the requirements. Etc. How long was the discovery and design document phase on the 2 year project?

AmericanChopper 7y ago
For every project I work on, I make sure I understand the problem, define the requirements, design the solution, and validate any necessary design patterns before I begin planning the implementation. How long that takes depends on the scope of the project, but I have never seen a project save time by skipping that bit. I also end up being pretty accurate with my time estimates.
- tsimionescu 7y ago
  What I have seen several times with that approach is a wonderful plan that needs to get scrapped about half-way through when the requirements suddenly change, for various market-related reasons. Some sketch of the end-design is always important, thinking about major components and future evolution, but a detailed plan has never been worth it in my line of work.
  - AmericanChopper 7y ago
    If you’re making radical changes to your design half way through, then you didn’t understand the problem you were trying to solve to begin with, and possibly didn’t define your requirements properly either. If small changes to your requirements mean you need to do significant redesign, then you didn’t design your solution properly. The most generous way to view what you described is that you’ve had to cancel your project half way through and start a new one. There’s nothing you can do to make business decisions like that work smoothly. In my experience though, a more likely cause of what you’ve described, is that the project was just planned poorly to begin with.
    - tsimionescu 7y ago
      The problem I was alluding to is exactly one of requirements - requirements aren't always exact, and they may change in unexpected ways as time goes on. In my experience, this is relatively common when building products that have a long time to market: since there are no hard requirements to begin with, just guesses on what features would be useful to have, it is easy for different marketing and product people to have different opinions and change their minds on what is or isn't an important feature.

chrisweekly 7y ago

A 2-year horizon -- even for massive, strategically sound projects -- is a non-starter, simply untenable in virtually every situation I've encountered in my 21-yr career in software dev and mgmt and consulting. Not saying you're wrong to think and advise in those terms, just that the opportunity to do so is exceedingly rare. Big public companies tend to be overly constrained by quarterly myopia, and startups usually don't have runway to attempt to plan that far out. Personally, I once endured a project being shelved after 15+ months of solid, productive effort. I've also been the catalyst, at least twice, for adoption of paradigm shifts that ultimately spanned ~2yr timeframes (one was performance as a first-class citizen, and another was incorporating RWD (responsive web design) into a large company's MO. These successful cross-cutting / interdepartmental changes took time, but I don't think either of them could have happened if they'd ever been pitched up front as multi-year projects. Maybe you've just been luckier finding far-sighted decision-makers. (If I seem bitter, I'm not. Just sharing my lived experience.)

mathgladiator 7y ago
I think it depends on scale and the inertia involved, and my original point was that accurate estimation is possible. There are many other challenges as you point out. I am currently on year two of a five year project. The key (and part of the essential difficulty) is finding quarterly or six month valuable deliverables that help ease anxiety of everyone involved. It is not easy, but it is possible. While all this is going on, I'm also working on a design document for a potential 10 year project. I doubt that I will pull this one off since I'm having difficulty finding those quarterly deliverables, but I'll keep grinding away.
- chrisweekly 7y ago
  Right on. Good luck!