5 ms·

As a leader/manager it is essential to spend your time on the right thing. Sometimes that might be coding, most of the time though, it is not. Mike Michalowicz

• grecy 2y ago
  > Sometimes that might be coding, most of the time though, it is not. I agree 100%, though I will add it is important to have a manager who can do, so that at the very least they can have technical conversations. Nothing worse than a manager who has no concept of what the doing even is.
  • willvarfar 2y ago
    For a good IC it might feel important that the manager understands engineering and has domain knowledge, but for the organisation it is import that the manager understands engineering and has domain knowledge so they can work out which ICs are good.
• alxlaz 2y ago
  That's a cool conceptual framework but like all conceptual frameworks it's meant as a simple, immediate rule of thumb, not a theory of how engineering management works. In practice, the last three Ds depend heavily on familiarity with the first one, as they ultimately boil down to steering it at (team) scale. Without it, you're going to decide the wrong thing for what your team needs to do, delegate the wrong things to people who can't do them, and ultimately design an organisation that can't do shit. Actually doing it isn't the only way to attain that sort of familiarity but for lots of people it's the only one that works. For them it's anything but the least important type of action a leader can do. Once they stop doing it at all, the clock of knowledge obsolescence starts ticking and all the other Ds atrite, as they inevitably end up deciding, delegating and designing based on yesterday's realities.
• mewpmewp2 2y ago
  The problem is that if you don't do much, you will get out of touch and all the other Ds will be coming from a place with little understanding. I have seen it a lot, especially with companies growing larger. Then they focus on the wrong things due to telephone game between layers.
• pavlov 2y ago
  Maybe it’s just my own bias because I love prototyping… But I feel in software engineering there’s a fifth D that combines the first and last items on this spectrum. (Sort of like magenta is a color that’s produced by the mix of wavelengths at the opposite ends of the visible spectrum.) Designing by Doing can cut through a lot of wasted time. If a principal engineer builds a working prototype, it can immediately move the discussion past the “Is that even possible or realistic” stage where lots of ideas go to die. Leading by doing is often a much better use of an experienced engineer’s time than promoting them to an architect role where they produce diagrams that nobody barely looks at. Design isn’t a panacea.
  • vishnugupta 2y ago
    I agree 100% to this. I use analogy of Scout in Age of Empires game. Scout allows one to explore the terrain, mark areas of resources, enemies, their civilization type and hence strengths/weaknesses. Similarly prototyping enables simultaneous exploration of problem space and solution space. After prototyping one can propose a design/architecture which is rooted in ground reality. You are more clear about upstream/downstream dependencies. Might even uncover gaps in product specs.
• DrScientist 2y ago
  The whole premise of clockwork is to setup a system that's self sustainable to make you money with minimal effort - it's a book for owners. If everyone in the business worked like this - carving out roles where they get paid, but did next to nothing, then I suspect the business wouldn't do very well.
  • ricardobeat 2y ago
    > carving out roles where they get paid, but did next to nothing, then I suspect the business wouldn't do very well That's exactly what happens at big tech companies, except the business can be doing so well that the impact is only felt on a 10-year timeline.
    • blitzar 2y ago
      That's exactly what happens at big companies and a bunch of midsized companies.
    • DrScientist 2y ago
      And perhaps worse than doing nothing - because they do have to occassionally have to justify their role - they need to initiate/be involved in big transformational projects every so often. At best these just cost money, at worse they get in the way of the real work. Obviously sometimes you really need these sort of projects - led by people who are truely trying to transform things - the problem is when it's led by people whose sole aim is to look busy by creating busy work for others.
• toolslive 2y ago
  This one is new to me. I know of 3D: Do, Delegate, Defer
• vishnugupta 2y ago
  Those 4Ds are so abstract and tautological to the point of being useless. As a practicing line EM I spent most of my time hiring, project management, people management, networking, resolving conflicts, mentorship, to name a few things of the top of my head. But all of this was built on a solid foundation of the system my team owned. And that was only possible if I understood things at the code level how various product flows worked. And I personally can’t understand code unless I fiddled around with it.
  • jf22 2y ago
    Some of these "frameworks" are always something like "just do the right thing." As if that is ever easy to understand.