Hacker News Reader

Comment by tagyro | Hacker News Reader

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's Clockwork has a really nice framework, called 4D:

- Do - the least important type of action a leader can do and where they should spend as little time as possible

- Decide - a level higher, but still not the core activity for leaders. Being the decision makes means that they have to be informed about everything.

- Delegate - this is an important skill for leaders, assigning who is responsible for which outcome

- Design - the most important type of action: designing the organization of the future and creating the right conditions for that organization to emerge; Put differently, this is truly working ON the business rather than IN the business.

View on HN

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.

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.

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.

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.

Some of these "frameworks" are always something like "just do the right thing."

As if that is ever easy to understand.

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.

> 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.

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.

That's exactly what happens at big companies and a bunch of midsized companies.

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.

> 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.

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.

This one is new to me. I know of 3D: Do, Delegate, Defer

Reply on news.ycombinator.com