So, project management huh?

(I haven’t had the energy to discuss much of anything in tech-verse lately, so I’ll make this about my views on it. I understand it’d be best to back these point of views with data, but hey, take it as you will.)

You have an idea for a product and you need to hire a team to build it. While its purpose is clear, the implementation isn’t, so you chase after a CTO, a.k.a. technical cofounder, to help clarify that. You two discuss things somewhat, and decide to hire a designer and a couple of developers. You all get together and outline the ideas, the designer sketches a few screens and hands it to the developers so they can implement it. That rather vanilla scenario will be the basis for the reasonings below.

Programmer efficiency is a function of their ability to delineate modules and of their prescience regarding the growth of these modules. How good is the strategising with these two variables will make or break the long term technical viability of it. They can bank against the future time and make concessions — and the word bank is very fitting in this case because it will have to be paid with interest — for short term gains aligned with goals that depend on external factors such as demos for investment sake. That’s not inherently wrong. Like in finance, whether or not it’s a good plan depends on you having an idea of how and when it’ll be paid before it starts costing a lot of money (or time).

The time a programmer spends doing a task is, obviously, in its bigger part dependent on core competency. Meaning: the more technically skilled, the faster it gets done. But there’s an aftermath to any code that gets written which is that a cost is added to the project in the form of maintenance, documentation, and discussions. Again, higher or lower depending on core technical skills. For example, creating module interfaces (or APIs) ahead of when they’re necessary can be a net gain in a short term strategy of building a feature subsequently, or conversely, a mistake if things evolve in a different way and now it’s throwaway code or even the source of bugs.

That in turn is reflected on the task list. Now, you can make that task list in any format you want, from cards on the wall to GitHub issues. The purpose of this task list is twofold: communication between the ones holding the spec defining how a feature/screen/module, and tracking the task’s completion. How much communication is needed depends on how detailed the spec is. If the sketch for a screen is vague and fails to specify various what-ifs, the implementation will probably be misaligned with the stakeholders’ expectations. If you were purposefully vague when sketching for time-sensitive reasons, what you did, in reality, is you banked against this very situation. This may or may not have been a good move, but the cost of it has to be paid, and if you can afford it, great.

Design is a significant part of this equation because mistakes made here have far-reaching implications both technical and more directly monetary, in the case of poor UX. Incorrect/inefficient workflows can lead to entire groups of tasks being partially or completely invalidated. The all to common scenario of design directed by the CEO is especially prone to that. The designer’s role, due to its proximity of the stakeholders, is the one that benefits the most from thinking of designs in terms of specs or solid agreements deserving of proper thinking-through.

The admittedly simplistic journey above (so as to fit in a short essay) leads to a conclusion: there’s no intrinsic need for complex management tools for facilitating communication. There is though a need based on your hiring decisions and on your people’s general talent for writing (language precision), focus (reading attentively, time management), and the stakeholder’s capacity to convey product goals correctly. No one is perfect, so I’m not arguing for doing away with all of it, but pointing out that when process becomes so complex as to warrant the use of tools that require the average person to spend any significant amount of time learning it, it’s a symptom of a gross lack of one of more of the aforementioned traits. A team growing is not by itself a fair reason because it’d be best to then split the teams up to allow for more modular management (thus shifting the cost of communication to people whose roles are arguably about that, namely, managers). Whatever risk that the tool is deemed to insure against predicates said risk on the problem being communication alone, often by ignoring how much the process adds to the risk by virtue of costing time, or more subjectively, shifting the incentive to solving card-issues to detriment of a more holistic view of the project.

Splitting teams up leads to frameworks for managing teams, not unlike in code when certain tasks deemed repetitive and outsourced to a library. And again not unlike in code, there may be best practices for applying it to specific problems and this is where most will (in both cases) trip and fall. But even in the hypothetical of it being 100% correctly applied, it mainly is about the negotiation of complexity among its moving parts and this will always come down to people’s ability to express their ideas correctly, in writing or otherwise. That is: a direct product of core competency.

This unearthing of the essentials has a purpose: illustrating that no amount of thought-leadership can erase the simple fact that you’re shifting time and complexity from one place to the other. What exactly is needed in terms of tools (for communication or otherwise) should hardly the product of set rules if the decision-makers are to be honest and not deposit the risk on the off-chance that someone else’s approaches may fit like a glove in whatever their own scenario is.

The final and more important point of this piece: education trumps any management effort because it’s the only action that tackles the problem directly. While management is about containing the complexity leaks, education is about stopping the production of thereof. Keeping management and its tooling thin and investing time and talent instead in training creatives improves the quality of the yield, makes for a more pleasurable environment, and is more time efficient in the medium-to-long term.