Hi, my name is Yuriy Nii and I am working on YOTEY, a project management tool which is a bit different.

Yes, I know: there are dozens, probably even hundreds of project management tools, some older, well-known and established with even more newer, sometimes obscure. Nevertheless and ignoring that, I wanted to make something for myself, to try out a specific idea which formed in my own context and environment; you know, "solving your own problem".

As for the said environment, I have been a software engineer and architect for 15 years, working in teams and on projects adjacent to hardware, embedded systems, machine control, factory and logistics automation, design tools, administrative, HR and other similar LOB application software. I have seen my share of greenfield, brownfield and maintenance projects of varying complexity and scope.

Unavoidably, I've also seen various ways and attempts of organizing work in those projects. It has been an interesting spectrum ranging anywhere between completely manual spreadsheets, at some point proudly extended with simple scripts by non-technical project managers, somewhat half-baked in-house dedicated tools built by software engineers on behalf of those same PMs and big expensive "cloud solutions" by respectable suppliers with, nevertheless, varying reputation among engineers. (By the way, did you know that the giant beam-spewing ancient dinosaur is actually called "Gojira" in Japanese? Now you know.)

I can't say that the topic of project management in general and productivity tools in particular always belonged to my interests. Yet as projects grew in size and complexity I developed appreciation of the piece of mind and smoothness of organizing the work itself, as a mirror of organizing smaller and larger bits into a technical design. These two aspects should go together as complementary dimensions, especially when viewing projects from the technical point of view. Development work on a system naturally follows its design and sometimes informs and affects it, so why not make this explicit in a project management tool?..

None of the tools I happened to work with offered a satisfying answer. Surely, one could define tasks, epics, labels and what not, but there was no structure deriving from, connecting to and reflecting the system and its design. No feeling of working on the system but mostly of somewhat related administrative work. It did not seem to bother others, but the gap between a conceptual plan, a sketch or even rather concrete idea for the final product or goal, its parts, components, modules, etc. and the means of expressing what needs to be done to get there, kept widening for me. As a software architect, I could sketch a structure of a system, describe its sub-systems and their relations, imagine the amount of work needed for each component, break the work down in concrete steps, discuss and review this with the team, convey all of this in a live conversation pointing at some diagrams on the whiteboard, just to be forced to throw away some of this and compress the rest into a less rich structure provided by a project management tool... Just like lossy compression makes the same source material less information-rich and fun. No more pointing at self-explanatory diagrams once Gojira approaches.

Then there is the question of whom the project management tools are meant for. Domain experts, customers, company managers even sometimes project managers are, understandably, far from details of actual technical work; it is simply not their job. It is natural for them to think on the highest, often ambiguous level of detail: "We wrote down this one issue, what else could be there to it? It doesn't look difficult!". Issues or tasks which are (too) high-level easily seem satisfactory to non-engineers and, on the other hand, impose expectations on engineers as if all is clear to proceed smoothly and deliver that new feature or product. Even worse, attempts at translating them into actual technical steps, sub-tasks, etc can be met with caution or even resistance because of perceived "scope creep" or scary technical formulations which seems unnecessary. Whenever this happens, project management tools have been taken over by someone else and end up nog being for engineers. We should not abandon the dynamic and frequently changing nature of creative technical work with all the brainstorms, sudden insights, problems discovered or shortcuts taken for the sake of "calm", static project boards which look controllable and steady to project managers and customers.

I believe that we should a) explicitly distinguish the two audiences of project management tools and b) cater for them correspondingly. For customers, account managers, domain experts, company managers and so on, the "issue level" is sufficient and most useful; it is the what and the why in a project. Engineers translate those into the what exactly and how, which are necessarily on a different level of detail and could be considered as noise, even unnecessary distraction for non-engineers. Issues are simply not work when we apply the principle of separation of concerns to project management. Therefore, I started thinking about a tool with native support for this level of detail without compromises of all-in-one applications. A tool specifically for engineers. Of course, others are welcome to peek as well! See, it is never so simple that just creating an issue is enough, even if a screenshot is included :-)

Speaking of all-in-one and compromises, what I mean by that is feature bloat, unclear focus, intended purpose scatted everywhere and the impact on ease of use and user satisfaction. Many well known tools are big, super customizable, support seemingly all scenarios and workflows and... are difficult to learn and to use. Even if they excel in some workflows, there is so much noise that it is difficult to appreciate the tool. Especially when some functionalities of an all-in-one seemingly exists almost for the sole purpose of making the tool big, impressive and expensive. The market is full of competing masters of none, masters of complexity, slowness and frustration. Plenty of reasons why so many at some point just try that clean and simple spreadsheet!

Admittedly, opinions on this vary, just as preferences regarding what workflow to apply or how to use a general-purpose tool. As an engineer, I want a simple, no-nonsense tool without numerous customization options I will never use, obscure fields I will never fill in, bloated UIs and huge input forms which deter me and fellow engineers from entering useful information (sometimes a lot of it), even on the days when we do muster energy and good intentions to do something useful with a tool clearly not meant for us and not so clearly for whom exactly. As a technical person, have you also ever received remarks from the business colleagues about taking notes in a simple text editor, instead of that one ubiquitous word processor? Yes, that same feeling. In other words, a specialized, one could say opinionated project management tool with minimalistic UI, ease of input, speed and without cognitive stress.

YOTEY is a project management tool which is my own answer to this mental approach to personal and team productivity in technical and knowledge-intensive projects. Summarizing, YOTEY is about:

• Bridging technical/design/engineering work and project management.
• Focusing on detailed visual work break-downs and concrete tasks instead of (only) issues.
• Clear separation of parallel ongoing projects, topics and sub-projects.
• Encouraging frequent, dynamic and up-to-date task management which is not static and useful daily.
• Supporting knowledge sharing, collaborative planning, risk assessment, team onboarding, work transfer and shared responsibility about the end-product by fusing engineering and project management in a design tool-like work modeling environment.
• Reducing project risks and improving predictability by making engineering complexity more explicit, discussable and visible, literally.
• Minimalism, ease of use and efficiency.

I think this focus and the concrete realization of YOTEY is different from many mainstream project management tools. As of this writing YOTEY is available in the free Beta, containing, for now, a modest core of this manifest. It is only fitting that all development work on YOTEY has been modeled as numerous plans in YOTEY itself. Additionally, I have been applying it successfully to other projects in a more wide context, in combination with separate, high-level issue tracking. The results, experiences and feed-back have been encouraging and gave me many ideas of what can be done by developing the core idea further. I am excited about extending the current MVP and pursuing the ideas and ideals I presented above.

At the same time there is no denying that the topic of productivity tools and project management is very wide. Personal and organizational circumstances and preferences are uncountable. Of course, general-purpose project management tools have their place, as do issue tracking, working with simple calendars, spreadsheets, ultra-customizable forms and so on. Luckily, the huge scope means that variation and trying something different always makes sense. If the YOTEY variation seems fitting your needs and makes sense to you, take a look at the YOTEY web site for more and to contact me with feed-back, remarks or ideas.

Thank you for reading and happy creating!