Haupz Blog

... still a totally disordered mix

Finisher Metric

2022-11-26 — Michael Haupt

Talking a lot about measuring output, outcome, impact, ... How about taking a step back, looking inward and seeing how a team is doing by looking at some input metrics for teams? As usual, John Cutler nails it. All of the metrics he proposes make sense.

In addition, I'd like to propose another one: in a given time frame, the ratio of things finished to things started is less than or equal to one. This indicates that the team is finishing more than (as as much as) it starts, which is generally a healthy attitude. This metric scales nicely from individuals over teams to entire companies. Where things like Jira are used, it should also be easy to implement and visualise.

(Also consider reading this one on the idea of finishing more and starting less.)

Tags: work

Integrity

2022-11-19 — Michael Haupt

Integrity is important, and not just for people in leadership positions. While that's a truism, it's also important to bear in mind that someone can be acting entirely with integrity and still found thoroughly disagreeable. In such cases, it's likely that the people involved have different value systems. That doesn't necessarily make one of them objectively wrong. Their different value systems give them different frames of reference, and it may well be possible for them to find some common ground yet. Making the conversation about intentions (what is to be achieved) rather than positions (how is it to be achieved) can be a worthwhile first step.

Tags: work

Independent Executors

2022-11-12 — Michael Haupt

Jade Rubick here describes the Independent Executors pattern for team organisation. It strongly reflects how I like to think about team independence, autonomy, empowerment, and collaboration. A key quote describing the way independent executors operate is that they "ask, but never expect other teams to do work for [them]". Let that sink in.

When an organisation operates as a maze of dependencies between work-in-progress parallelised across many teams, the dependencies take control, and communication between teams devolves into priority haggling, instead of being about delivering the actual work. That slows everything down, sometimes grinding to a halt. If teams are set up as independent executors instead, they know full well where there are dependencies, and they know how to resolve them using their own means if the team they depend on cannot do it. This, too, can be seen as slowing things down, but the "grinding to a halt" bit won't happen. It also means that deadlines don't work, because they may all too often just assume that all dependencies will be resolved by others' delivery.

Of course, this means a more holistic approach to planning the work in teams, and requires greater expertise (seniority) in team members that need to have more than just an idea of what that other code base is doing. That can also be less than ideal, as any sufficiently complex software architecture will tell you. The independent executors model cannot just be imposed on unsuspecting teams struggling to operate in a complex environment.

Taking yet one step back, what is needed from the environment to enable teams to operate as independent executors? In one word: clarity. In some more words: clear priorities that just make the answer to the question of which project is currently the most important one completely obvious. Any team that directly contributes to that most important thing is guaranteed to get support. Any team that cannot directly or indirectly support that project can either resolve the dependencies on other teams for itself, or focus on its tech debt, take some training, or whatever. Not to forget, no team not currently contributing to the "most important thing" can be expected to deliver to any deadline (self-imposed or externally given) that involves relying on dependencies. Essentially, this is the approach using thematic goals, defining objectives, standard operating objectives, and measurements (straight from Lencioni).

Providing that clarity takes courage, from the top. It's a leadership responsibility. Period.

Tags: work

Distractions

2022-11-06 — Michael Haupt

With distractions, it's not their magnitude that's a problem, but their multitude.

A distraction of a major magnitude is usually both urgent and important enough to warrant immediate attention. Those should be rare.

Facing a constant flurry of many small distractions, however, is problematic. It leads to regular interruptions involving urgency and importance analyses, and thereby hampers any healthy flow state. Moreover, even if handling the distraction is not ultimately "my job", it needs to be managed and probably followed up on, increasing the amount of work in progress.

Distinguishing between work (delivering on the tasks we're supposed to deliver on) and meta-work (delivering on organising one's work), it should make immediate sense that work should take precedence over meta-work, always bearing in mind that the latter cannot reasonably be zero. The effect of facing a multitude of distractions then is that the amount of meta-work exceeds the "healthy" threshold.

How should the balance look? What's "healthy"? I suspect that meta-work should take a small (single-digit) percentage of overall time.

(This is also related to the idea of finishing more, and starting less.)

Tags: work

The Spotify Model

2022-10-31 — Michael Haupt

There's still a certain hype around the "Spotify Model", even though Spotify isn't implementing it any more, and even though it has not worked all too well there. The hype probably stems from the catchy terminology, temptingly suggesting orderliness and maximised freedom for everyone involved at the same time.

Thing is, one does not simply design societal structures; they emerge. History teaches us that attempts at the former will rarely succeed, and the few successes rarely function well when used as templates. (Of course, the bold implication here is that companies, or product organisations, are "societies" - they are, at a certain level of scale.) The same holds for company culture: one doesn't design (and impose) it; it emerges from the things people at the company do.

In both these cases, desirable changes happen not by prescribing the new situation, but by giving an objective, creating the incentives that make it a desirable and worthwhile goal to work towards, and by constantly reminding and setting examples. For example: You want more agility in how the place is running? Make it measurable, observable, starting from first principles and with what you have - and live it from the top down.

The way a company works is part of the culture. The two are inseparable. And emergent.

Tags: work

Finish.

2022-10-09 — Michael Haupt

Leeor Engel wrote down a bagful of wisdom on priorities, parallel and unplanned work, team structures, and more. I highly recommend to read it, and will add some of my own thoughts here, expanding on some hand-picked items from the article.

There's one bit titled "finish what you start", and that's all too important, as well as all too easy to get wrong. Starting something new always has this magic feeling about it ("... jedem Anfang wohnt ein Zauber inne ..." as Hermann Hesse aptly put it). That new technology / tool / language / library / framework right there, that's so good, we have to use it. Never mind the cruft we haven't cleaned up yet, we'll eventually do that ... sound familiar?

Finishing is strictly more important than starting, and while starting something may be more exciting, finishing is where the value lies. The Pareto principle is right: the first 80 % of the work are done in 20 % of the time, and then it gets daunting and tedious. Getting something up and running as a prototype is easy and fun. Shipping it as a product involves lots of attention to detail, rounding off rough edges, and work, work work.

An interesting metric for every team or individual is to look back on a week, sprint, month, or other period of time, and see what the ratio of "things finished" over "things started" is. A value greater than or equal to one is encouraging, a value below one can be a sign of problems ahead.

This topic is directly related to the question of how many things to drive at the same time, and the article has a section suggesting to "prefer a single stream of work when possible. 2 max." - that is indeed highly recommendable, at all levels of an organisation. The greater the degree of parallelism, the more time needs to be invested to manage said parallelism. The impact of dependencies between different teams working in parallel - and it is natural that there are such dependencies - will be heavier when there's more going on at the same time.

Patrick Lencioni suggests to have one "thematic goal" at a time - as an organisation, mark you! - and get to the next one only what that is achieved. This ensures focus throughout the organisation, and naturally does away with any doubt about priorities.

Tags: work

Management Styles

2022-10-01 — Michael Haupt

What a nice little catalogue of management styles this is. Mine is a mix of 1+3, with a bit of 5 and 6 and a very occasional nugget of 10 (if I have to). Or so I believe. People should just tell me.

On a somewhat more serious note, this is an interesting guide not just for managers, but also for people who are thinking about switching career tracks to take on managerial roles, or who have just done so. I believe that two things will be true about the ultimate style someone exhibits:

  • First, it's going to be a mix of some of the ten styles, and never just one. Add in some situational sensitivity, and that becomes a good thing.

  • Second, it'll emerge from someone's personality rather than being a conscious choice. The latter may be possible, but the acting will show, and it'll look (and feel) unnatural.

The catalogue is even helpful for people in individual contributor roles - it can help them recognise certain behaviours and can serve them a framework for giving feedback in case they feel their manager isn't doing quite the right thing in certain situations. (Heck, I'd appreciate being told I'm in bureaucratic mode when I shouldn't be!)

Tags: work

Outcome Over Output

2022-09-18 — Michael Haupt

In the light of what I wrote about reducing the whole agility hoo-ha to just two questions for everyone to ask themselves some time ago, this article has some nice insights on a common misconception that has agility confused with speed of delivery. At a lower level and applied to software development, the confusion often is about project management vs., well, software development. If we measure velocity, we don't measure quality. Ultimately, what we should care about is quality, not velocity. Our customers most certainly care about quality more than about velocity. A prematurely released update that introduces bugs just doesn't land well. Anyone who ever installed a major macOS upgrade before the .1 version came out will know what I mean. But I digress.

Do yourself a favour and read the article, please - and in the two-questions framework, doing the most important thing can also mean to have a measurement in place that actually measures what's being delivered, instead of how much time is invested.

Tags: work

Communication Traps

2022-09-04 — Michael Haupt

When communicating, we can fall into some common traps - and it's not just people in leadership positions who are prone to falling into them. I'll give them each with a headline including a symptomatic phrase, description of how one's behaviour looks in the trap, questions one can ask oneself to validate one's position, and suggestions for behaviour to get out of the trap.

  • The solution trap: "I know how to do this!"

    I'm being prescriptive rather than collaborative, I come with a canned solution rather than allowing one (probably better?) to emerge from discussion.

    Do I really know better? Am I bored and want this conversation to end?

    I should put myself in the other’s place, take their perspective, and try to ask myself open questions from there.

  • The ego trap: “I’m right about this!”

    I'm imposing yourself on others, rather than seeking common understanding.

    Am I really right? Am I too lazy to explain my point?

    I shouldn't counterargue. I should avoid using “but” / “no” / “however”; I should rather respect the other’s view and develop the next iteration from there by offering alternative perspectives.

  • The judgment trap: “This is why you did that!”

    I'm jumping to conclusions about the other’s motives rather than thinking about what might drive them.

    Am I seeking confirmation for some prejudice I have? What prejudice might I have? Might the other be after the same thing as I?

    I should assume good / shared intentions and ask questions to understand.

  • The Sinatrap: “Do it my way.”

    I'm imposing my way of doing things on the other rather than letting them find or follow their own way.

    Am I so convinced of my way that I don't see merit in any other? Do I just want the other to follow my rules, am I defending some ground?

    Unless actual harm is done, I should let the other be and seek to understand why they address things the way they do.

There are many overlaps between these, and the differences are often nuanced. They lie in the ulterior motives, which the validating questions hint at.

How does this work?

Tags: work, coaching

Agile

2022-08-20 — Michael Haupt

I'll be bold here and try to wrap all things agile in just two questions. Let me know what you think.

The first one is this: Are you currently surely working on the most important thing the company needs from you?

If yes: good! Carry on!

If no (and this is the second question): Is it (a) because you're distracted/impeded or (b) because you don't know what the most important thing is?

In case it's (a): removing the distraction or impediment is now the most important thing the company needs from you. In case it's (b): finding out about the most important thing is now the most important thing the company needs from you. Communication is key in both cases, that's knowing, finding, and involving the right people.

That's it, no process hoo-ha is needed.

Process can (and will) emerge from applying this, e.g., having daily check-ins to regularly answer question 1 and ensure to stay on track, or disciplined paces to take note of distractions and impediments that keep happening (read: retrospectives).

Basically though, these two questions suffice and everybody should be empowered to be consequential about them.

Nuff said.

Tags: work

Mature Programming Language Ecosystems

2022-07-23 — Michael Haupt

I used to work a lot with, and on, Java, so I have a soft spot for that language and ecosystem. One specific point I've come to realise while dabbling with some tech and reading about log4j problems over the past months is that a rich standard library (like the one that's part of Java) can make you a lot of days. The following can easily be misunderstood as flamebait. Please don't.

The log4j misery could have been avoided - the Java standard library has a built-in logging facility since JDK 1.8; and a capability for remote code execution simply isn't needed in a logging library.

Dependencies can be tricky. On Windows, there used to be DLL hell; today, we have npm dependencies that have a tendency to go really awry. Yes, Java has its issues too, when there are hard-to-resolve conflicts between dependencies managed by Maven, for instance. But back to npm. The JavaScript language is very small, and it and Node.js don't come with a very rich standard library. Consequently, many "standard" things end up being pulled in as dependencies through npm. Also, everybpdy (and then some) thinks it a good idea to release their particular solution to a recurring problem as an npm module.

The maze of dependencies, sometimes conflicting licences, and outdated or insecure code becomes ever harder to navigate, leading to yet more software being built to help developers and companies (who don't want to lose lots of money in licencing or software security lawsuits) to handle the complexity. That means there's businesses flourishing on the fallibilities of the ecosystem, rather than fixing those.

Sometimes modules are pulled "just like that" (because the developers can), and sometimes this happens for the worst reasons, e.g., because a developer cannot make a living from software they hand out for free after their apartment burned down. This points to a deeper problem with open-source software: it's taken for granted. And if a maintainer doesn't have a company behind them that helps with paying the bills, it's a precarious gratitude those developers are showing.

Libraries and dependencies growing out of proportion is an issue that can be addressed by relying on an ecosystem that comes with a rich standard library to begin with. Java is at the heart of one such ecosystem, and it's being maintained and developed in a very sane and transparent process, by a very capable and mature community. Some big industry players are part of that community, and fund a lot of the work. I'm using Java as one example - there are others.

What's my point? There are several:

  • When choosing technology that's meant to run a business, erring on the side of true-and-tried ecosystems with rich standard libraries and robust buy-in is safer.

  • Where vivid open-source technology is used, consider funding it in addition to using it, to have a visible stake.

  • Technology should be chosen for the right reasons. Therefore, it doesn't need to be hip. It needs to work, reliably and sustainably.

  • Working with true-and-tried (some might say "old and boring") technology does not substitute supporting research into new, innovative things that can be the true-and-tried ones ten years from now.

Tags: work, hacking

Elephants, and Emperors

2022-07-09 — Michael Haupt

Sometimes there's an elephant in the room. Sometimes the emperor wears no clothes. And then, sometimes, the elephant in the room wears no clothes, and that's when it's really important to speak up.

That works best when there's psychological safety. In spite of its name, it's not at all a touchy-feely concept: it takes a lot of hard work and courage to achieve, foster, and sustain. It begins with building trust, and involves freeing the workplace of fear.

Psychological safety also has nothing to do with being nice: rather, it's all about being kind when raising concerns and issues. Being nice just leads to tiptoeing around issues (see above about naked elephants) but never resolving them. Being kind, conversely, means that necessary criticism can be brought up, and that it comes from a position of support, not revenge; with a spirit of caring, not blaming; in a culture that makes issues transparent to learn, rather than retaliate.

Tags: work

Look After Yourself First, Then Help Others

2022-07-03 — Michael Haupt

That thing they say on airplanes when they talk about the oxygen masks - first help yourself, then help others - may sound like an invitation to selfishness, but it's actually completely sensible. Without that mask on, I might faint, and couldn't help anyone then. If you don't look after yourself first, you may end up being unavailable for helping others.

The same is true in everyday workplace situations. Caring about one's teams and colleagues is important, and it won't be possible after some point if there's no self care. This little thread on Twitter really hits home on that.

Tags: work

Urgency

2022-06-25 — Michael Haupt

"Urgency" is another one of those terms that get thrown around a lot, and it's often used to push people to work more, harder, or in a more haphazard way (as in: reacting to "urgent" priority changes). That's not right. "Urgency" is in itself a good concept, and should be used to keep what's really important at the forefront of people's minds, in a unanimous fashion.

Have you ever faced a situation where a piece of value was ready for release but someone had a last minute concern, addressing which would not significantly improve user value but cause several days of holdup? That, right there, is the opposite of urgency. This kind of one-upmanship is ultimately detrimental to customer value. We have no right to withhold from our users any value that's ready to be shipped. Minuscule improvements can be rolled out with the next release.

A healthy sense of urgency instils a shared knowledge of what's really important.

Here's a nice piece on some ways to consciously work on urgency as a team. There's something in there for everyone.

Tags: work

The Five Dysfunctions of an Engineering Team

2022-06-19 — Michael Haupt

I'm a bit of a Patrick Lencioni scholar, and will always be happy to find others applying his tools. His book The Five Dysfunctions of a Team is a classic - most have at least heard of it, many have read it, some are consciously applying the "pyramid" model, which has (to name the functions rather than the dysfunctions) trust at the foundation, healthy conflict one layer above, commitments and accountability next, and attention to results at the top. None of the higher levels can work without the lower ones working. Ergo, trust is the number one ingredient to a well-functioning team.

Here's a post that applies the model to engineering teams. (I have borrowed its title for this one, and added just some emphasis.) It gives a nice summary of the model in just two paragraphs, and then goes into detail about how each of the dysfunctions can play out specifically in engineering teams. Many of the observations apply to teams in general (as does the model), but the perspective is still valuable.

Random spotlight on the dysfunction lack of commitment: Do you frequently miss sprint goals? Do team members often work on things unrelated to the sprint goals? Are code quality standards ignored, and many corners cut? Those would be signs of lack of commitment - and before addressing them (there's always a next retro, right?), it's important to make sure the possibly underlying cause - lack of (healthy) conflict - needs to be addressed first, but not before the most fundamental one - distrust.

The model is quite solid, and implementing it takes a lot of courage. A lot. Its faithful implementation won't allow any distrust to slip through. It'll transform how team members interact - in a good way. Maybe the model's implementation will make some people feel uncomfortable with all the openness, passionate discussions, commitments, calling others on those, and so forth - but after all, every single team member is there for a reason, and that's the team's (and company's) mission and purpose.

Tags: work

We Are Not Family

2022-06-12 — Michael Haupt

For a long time, I've usually felt a tinge of discomfort whenever someone was mentioning the idea that we, at this company, are a family. (I mean no particular company here.) In fact, we're not, and it's important we avoid that analogy. Here's an article that I'm glad I found, because it makes many of the points that I couldn't properly formulate so far.

We all want to feel satisfaction from what we do at work, and we want the good work we do to be acknowledged. We want to be seen, instead of being anonymous. And all of that is possible in a workplace without that workplace branding itself as something that it inherently isn't.

We can't choose our family, and the family can't choose us. But we're all working where we are because we consciously decided to do so, and the company has us around because it decided to, by way of delegating that decision to a hiring manager. It's first and foremost a contractual relationship, and a social one only in the secondary perspective.

Tobias Lütke, CEO of Shopify, mentioned some other things that a company - here: Shopify - isn't.

Tags: work

Meetings, Context Switches, and Flow

2022-06-03 — Michael Haupt

I've always been sure that meetings per se aren't the problem when people complain about "too many meetings" and exhaustion therefrom, but that the problem is actually that many meetings we run are bad. Some reasons:

  • Unclear purpose (why are we having this meeting?);

  • Unclear what each participant can bring to and take away from the meeting (why is everyone here?);

  • Shifting "flight levels", e.g., when constantly moving back and forth between discussing strategic direction and technical implementation detail (what are we talking about?).

Zooming out and looking at the entire day more or less full of meetings, brain research has it that there's another problem (one that's also been known to be an issue due to common sense): frequent context switches. At times, I have days that are packed with meetings, and every single one is about something entirely different. Moreover, there are no breaks between the meetings (or just the ones that are absolutely inevitable for basic biological reasons). After such a day, I usually feel much more exhausted than after a day with a sprinkle of meetings with focus time in between, or one very long meeting that's about one thing only.

We tend to work best in a state of flow. Even the sprinkle of meetings I mentioned above can harm that, because the meetings interrupt focus, and if the focus periods are too short, flow won't happen. I owe it to the reality of my job that I work a lot with others in meetings, but then I'm supposedly on the manager's schedule, not so much on the maker's schedule. (I disagree with the maker/manager dichotomy, it comes across as if managers weren't making, and makers weren't managing ... but that's a digression.)

For anyone, a day with lots of meetings (even with different people) about the same matter can contain a lot of flow: it's the context switches that cause most pain.

Tags: work

Managers Have Boundaries, Too

2022-06-01 — Michael Haupt

Managers who seriously and deeply care about the people they're responsible for are also vulnerable in a special way. Let me explain.

(This is the result of some thinking over time, inspired by observations made over time in various places. This thinking is now ready to be written down. It also applies to all direct report / manager relationships, regardless of level.)

It's my responsibility to create an environment where everybody reporting to me can feel safe and well. I care about every single person reporting to me, and that's extra hard because sometimes I have to give them some tough love or negative feedback or say "no" to something or hold them accountable or whatever. Being in a managerial role makes these supposedly normal things harder because there's a reporting line involved.

The tricky bit is that someone who cares can easily be misunderstood as being soft, and - hold tight! - it is easy for someone who cares to misunderstand themselves like that, and err on the side of being soft. It's easy to sometimes confuse caring with not pushing back when a direct report crosses a manager's personal boundaries. However, managers have those boundaries just like everyone else.

Direct reports who have a personality that makes them very outspoken and direct communicators (and, let's face it, gives them a tendency to be overly judgmental), tend to cross those boundaries, very likely without even noticing. It does hurt a manager when that happens. And then the manager's caring instinct kicks in, and instead of drawing a line that's not to cross, the manager curbs their self defence.

Here comes the key bit. Such caring managers, too, have a right to not tolerate when that line is crossed. And it has nothing to do with not caring when a manager expresses that. It's a personal boundary that gets violated, and, again, managers, too, don't have to tolerate that. They also have a right to be heard before being judged, so whenever someone comes to their manager with a pre-formed judgment, it is entirely OK to draw a line in clear terms and invite them to (1) give their manager feedback instead (i.e., share what they observe instead of what they conclude from their observations), and (2) ask about the manager's motivation to develop some empathy. (Recall, feedback better be a two-way street.)

A caring manager has a right to erect those boundaries, and to enforce them. Being a direct communicator does not imply the right to be reckless. The sheer existence of reporting lines and direct report / manager relationships is often abused by people who like to see everything as power dynamics, and frequently what they mean is that managers have to take every kind of abuse because they're supposedly in a power position. That is complete nonsense. Being a manager, erecting those boundaries, and enforcing them is not power dynamics, it's asking for basic human decency, which everyone deserves.

Tags: work

Feeling and Being Fast

2022-05-21 — Michael Haupt

John Cutler continues to provide really insightful content. Here's a table of things that make us feel fast vs. things that make us fast. Three more or less random takeouts.

Starting vs. finishing. Starting something new always gives that exciting energy boost, right? In German, there's that poetic expression "jedem Anfang wohnt ein Zauber inne" (there's magic in every beginning - credit to Hermann Hesse). Indeed it feels good, exciting, refreshing. And yet, how much does starting something new every day get us closer to finishing anything? When is the last time you've finished something? In coaching, I've sometimes, when my clients had trouble with work-in-progress limitation, used the question "What is the ratio of things you started this week or month over things you completed in the same time span?" - let's say that a ratio greater than one, carried along over several time periods, indicates trouble. Let's be finishers.

Cutting corners vs. quality focus. A bug's life should be short. Ideally, it never comes to existence. With a strong sense of craftsmanship and with taking pride in what we produce, we will avoid cutting corners because it feels like cheating. We simply, plainly owe this to our customers.

Design then build vs. participatory design. How about having the frontend engineer and the designer sit down together and pair solve the problem they're facing, rather than having the former implement the design produced by the latter? Pair programming has proven worthwhile, why wouldn't pairing across functions? I've personally experienced exciting delivery throughput in a truly cross-functional team that spanned all relevant functions, from business stakeholder over product manager and designer to engineer. Everyone truly collaborating on the matter was absolutely compelling.

What are your comments?

Tags: work

Feedback and Goals

2022-05-14 — Michael Haupt

Here's another note on feedback, after one on feedback as a two-way street, and one on delivering feedback.

Today's entry is about this great piece on feedback. The piece takes a somewhat narrowed view on what feedback is, making it all about providing "information about how someone is doing in their effort to reach a particular set of goals", and introduces a tripartite view, naming the different forms of feedback "appreciation", "coaching", and "evaluation". Narrowing the concept down like this may look like an undesirable restriction at first - recall that my usual take is that feedback can be about any behaviour and impact. It's not a problem to accept the article's take as one particular, and very focused, framework. It has a lot of merit.

The article's approach, then, is about feedback as an assessment tool on the road to reaching goals. Appreciation is reinforcing what's working; coaching is understanding and addressing road bumps; and evaluation is deeply and honestly assessing where things are off. The article provides a wealth of details about this framework, including suggestions for how to frame conversations. It also sheds light on some pitfalls, two of which I find particularly important.

First, it's easy to overemphasise appreciation, leading to a culture where "being nice" is deemed better than "being kind". This is expressed in lots of praise flying around, and the amount of honest evaluation and coaching not matching that. It means that the real problems aren't touched upon, but sugar-coated by exaggerating praise. It's important to understand that one can give highly critical feedback whilst being kind.

Second, it's easy to underappreciate coaching, which is, after all, about approaching a situation with curiosity and the intent to understand. A coaching mindset makes feedback a two-way street, and makes it more about the person receiving the feedback than about the one giving it. It also empowers the receiver to finding a solution themselves, instead of being force-fed a desirable behaviour mandate.

Tags: work

Delivering Feedback

2022-04-22 — Michael Haupt

After this piece from a while ago about feedback having to be a two-way street, here's another refresher on feedback. It's a good and concise overview and a reminder of how feedback should be delivered: free of judgment, sticking to the observable, and to impact. I specifically appreciate the "don'ts" part of the article, with its reminder about timeliness, and avoidance of slamming the feedback sandwich.

I would like to add, once more, that feedback can be positive or negative ("praise" and "criticism") - you can observe and describe behaviours that have a good or a bad impact. I would also like to add, once more, that there isn't a dichotomy between "good" and "constructive" feedback - the latter is often used as a lame euphemism for "negative" feedback. All feedback should be constructive.

And please keep it a two-way street to avoid making it all about you.

Thanks.

Tags: work

Reverse Onboarding, or: Get Serious Quickly

2022-04-03 — Michael Haupt

Here's a list of questions an engineer can ask when newly joining a team. It's sort of an onboarding checklist "from the other side". Many of the things on the list are typically covered by what a team / company does to onboard a new hire, but the change in perspective is interesting. I highly appreciate how the list zooms out from the basics - development environment setup and such things - to customer feedback and stakeholder involvement.

Any team operates best - in the sense of serving the company's customers - when it is fully engaged with and feels directly responsible for the customer experience. This is true at all levels - from individual engineer over team and organisation to the highest leadership roles. Everybody should be willing and able to feel proud about what they do. Applying a strong sense of craftsmanship implies caring about customer experience and quality.

Building software is complex work involving many interdependent roles. Consequently, no one can claim to work in a silo of any kind. To give an example, if an engineer (sorry for picking on you, folks) remarks something like "testing isn't my job, QA does that" is problematic: How can you feel accountable for the whole if you simply hand your work off to someone? You're reducing yourself to a cog in a gearbox that way.

Instilling a strong sense of responsibility and stewardship for the product starts with pointing out the relevant interconnections during onboarding - and that's why I like that list so much.

Tags: work

The Moldau, Re-Listened

2022-04-03 — Michael Haupt

Too much routine can blind you for important things. In German, we call this "Betriebsblindheit" (roughly translatable as "business blindness"). It's the primary cause for having retrospectives in agile settings - a team that works very well can easily descend into self-complacency and "this is how we do it around here" mentality, blinding them for both chances for improvement of problematic behaviours and opportunities for amplification of good ones. Never stop observing, never stop reflecting.

I'll use a musical example. Bedřich Smetana's piece "Vltava" ("The Moldau") is, for the best of reasons, immensely popular and often performed. So often, in fact, that a certain fatigue can settle in. I've personally heard it so many times I thought I'd heard it all. How wrong I was. At some point, I stumbled over this performance, and it's new. The tempi, the way the orchestral groups are coordinated, the utter transparency of the melodic lines were simply striking. Granted, there are little glitches in the timing here and there, and the violins' forest nymphs motive is submerged in the woodwinds, but do take it in and revel in it. I can't stop praising this.

Tags: music, work

Reply-All

2022-04-01 — Michael Haupt

(Warning: maybe because it's 1 April, the post below contains a bit of irony. When you find it, feel free to keep it.)

You've seen them - congratulatory e-mails flooding your inbox, even if you're not on the receiving end of the celebration but merely a member of the cheering crowd. Thanks to "reply-all", they happen. I personally don't mind them much, but some people do take mild offence in being faced with the challenge of having to mark swathes of "congrats!" messages as read.

There's something to be said for both sides here. On the one hand, such a broadcast message, e.g., a promotion announcement, can be seen as primarily meant to notify the crowd of the news. Reply with heartfelt congrats, rejoice in the fact, cool, move on. On the other, the broadcast does have a social aspect to it in that it encourages the crowd to cheer, and he cheering gets amplified by itself.

Of course, there's an easy remedy. Instead of putting all recipients on CC, putting them on BCC and keeping just the intended recipient of the congratulations in the "To:" field will reduce the recipients of the "reply-all" flood to just the subject of the celebration and their manager (or whoever sends the message). The parties put on BCC can be mentioned in the message, for transparency.

I sense an actual research question in this: Will CC-reply-all flooding incentivise more people to congratulate the person, or will the ones who want to do this do it anyway? Is there an amplification effect in "reply-all"? If so, what does it amplify more, cheering, or grumbling? Does BCC-messaging have a contrary effect?

Who's in for doing an empirical study?

Tags: work, hacking, the-nerdy-bit

Things Leaders Want To Say But Can't

2022-04-01 — Michael Haupt

Here's a list of 13 things leaders want to say but can't. Number three is one I probably need to be told more often than I want to hear it, but there it is.

All the tongue-in-cheek aside, there's something serious about that list, which some of the points hint at. I'd like to emphasise that: if we're in a leadership role for the right reasons, most of us care, a lot, usually, most of the time. We can't always show it as accurately as you want it, because we, too, are bogged down in overwork, and we have some things we just can't talk about as openly as you'd expect us to.

Just this much: Please, never believe that your leader is leading precisely the way they want to. If you're frustrated by something we say or do, give us feedback and ask (empathy is for everyone) - we might not be able to give you the full story, but we'll usually be happy to explain what we can.

Tags: work

Toxic Leadership

2022-03-27 — Michael Haupt

John Cutler has an interesting list of signs of toxic leadership. While they all have to be taken with a grain of salt because intent matters and interpretations can be wrong, someone sporting numerous of these is probably contributing to a toxic workplace.

Remember, investing in mutual understanding and empathy come first - but still, I would really appreciate if anyone working with me sees me doing one of these told me so instantly. Likewise, should I do multiple of them for extended amounts of time, I'd like to be told, and my manager to be told, and HR to be involved.

Tags: work

Predictability

2022-03-25 — Michael Haupt

John Cutler has a really beautiful collection of things that hurt and help predictability. It's important to note that "predictable" doesn't mean "meet the deadline" but rather a way of working where you can be sure that your estimate for when you're going to be done is accurate, because you can be rather certain that there won't be too many surprises and distractions.

Having seen this collection, I immediately noticed that there are many things I've seen done and not done in my work environments so far, from both halves of the collection. Where is your team in this?

Tags: work

Meet or Not?

2022-03-20 — Michael Haupt

Here is a super lightweight tool to find out whether something should be a meeting or not. There's also a downloadable flow chart. I admire the pragmatism.

Tags: work

Next Level Home Office Setup

2022-03-20 — Michael Haupt

My coaching trainer Maik has an impressive setup for running his workshops. I took his ILAP training and experienced the setup first-hand. Thankfully, Maik has described the setup in detail. The main takeaways for me are OBS for scene definitions, and the camera-behind-teleprompter idea for maintaining better eye contact during video calls. I'm not going to copy this because my requirements are different, but this is an example of how dedication and determination can lead to a really amazing work environment that makes for smooth interactions.

Tags: work

Senior Engineer Skills

2022-03-19 — Michael Haupt

How about a list of skills for senior engineers? "Number 10 will blow your mind!" - On a more serious note, I think this list is great, and if you replace "engineer" with just about any other kind of function, most of the items on the list still hold, and it's actually a pretty nice collection of "senior" (read: mature) behaviours. Worth considering.

Tags: work

The Software Death Spiral

2022-03-19 — Michael Haupt

Something to watch out for: the software death spiral. How are we doing? Can we deliver as fast as we would like to, and do we take care of tech debt appropriately? The article has some interesting signs to observe, and offers some remedy.

Tags: work

Different Jobs

2022-03-15 — Michael Haupt

Here's some advice on leadership, with a somewhat specific view on engineering leadership. I agree with all of these points, and would add another one, as a variation on point 1 for those engineers pondering a switch to engineering management: being a good engineer doesn't make you a good engineering manager. This is because the management job is very different from the engineering job. It's a different job that requires very different skills.

Tags: work

Meeting Sentiment Analysis

2022-03-06 — Michael Haupt

Meetings, again. This article is another variation on the theme, but one that introduces an interesting solution angle to the usual whining. I spend a lot of my time during the week in meetings, and often see what the article calls "dysfunctional meeting behaviors (including wandering off topic, complaining, and criticizing)" - sometimes, I'm guilty of that myself.

Note that I will maintain my forever held conviction that there is no dichotomy between meetings and work, but that meetings are a form of work, and that the problem isn't meetings, but bad meetings.

The solution proposed in the article is simple (and that makes its implementation complicated because the devil is in the details): take inventory of sentiments, analyse them together, get serious about setting goals for the meeting (series) that have personal relevance for each attendee, monitoring progress on those goals, and having regular honest debriefs about the meetings.

Sounds enticing.

Tags: work

My Calendar

2022-02-19 — Michael Haupt

People frequently tell me how packed and insanely busy they think my calendar is. There are two sides to this story.

First, my calendar is simply brutally honest about my availability - it's transparent. If someone needs to talk to me and wants to schedule time, the white spots are available. I make it clear when I plan to work on my own ("focus") and what other meetings there are that I attend. This looks packed, but it's actually just what's going on.

Second, yes. There is a lot going on. I spend a substantial amount of my time in meetings of various kinds, and the frequent context switches aren't easy to handle. I might at some point just declare calendar bankruptcy and start it all over, but the calendar will always reflect accurately what I'm doing (see above), so the question is maybe not so much about the calendar but about a smart limitation of my work in progress.

Tags: work

Writing Documentation

2022-02-19 — Michael Haupt

This article argues that there are mainly two reasons why developers don't (often, usually) (like to) write documentation. Firstly, writing is hard, and secondly, not documenting doesn't block shipping. There are also some remarks on the value of documentation, and advice on how to go about ensuring there is decent documentation after all. I don't disagree with any of that, but that's not the point. I would like to expand a bit on the writing documentation is hard topic.

Back when I was working on JEP 274, which eventually made it into Java 9 in the form of a chunk of public API in the OpenJDK standard library, I wrote a lot of API documentation. This was a necessity because other implementers of the Java API, such as IBM, were supposed to be 100 % compatible but were, for legal reasons, not allowed to look at the implementation behind the API. So, that API documentation had better be rather darn accurate.

The centerpiece of JEP 274, a method used to construct loops from method handles, has a complex but nifty abstraction of loops at its core. (I fondly recall the whiteboard session where several of the wonderful Java Platform Group colleagues at Oracle designed the "mother of all loops".) When I had completed the first version of this, I put it out there for review, and started collaborating on the project with an excellent colleague, named Anastasiya, from the TCK group, located in St Petersburg, Russia.

It was Anastasiya's job to ensure the API documentation and implementation were aligned. She took the API documentation - which I was quite fond of already - and wrote unit tests for literally every single comma in the documentation. Sure enough, things started breaking left and right. During our collaboration, I learned a lot about corner cases, off-by-one errors, and unclear language. In a nutshell, my implementation was full of such issues, and the API documentation I thought so apt was not exactly useless, but irritating in many ways.

Anastasiya and I worked very closely for several months, and eventually, the documentation was not only in line with what the implementation did, but also precise enough to be usable by our friends at IBM.

Point being? Writing good documentation is indeed very, very hard, and I couldn't have done this without Anastasiya's help. Without her, I'd have ended up shipping public Java API - code running on dozens if not hundreds of millions of devices worldwide - in a really bad state. I'm still very grateful.

Tags: hacking, work

Daily Standup Patterns

2022-02-13 — Michael Haupt

Here's a collection of patterns for daily standup meetings, by Jason Yip.

I've been wondering a lot "who/what should be attending" standups, pretty much ever since I attend them. Should the people attend, i.e., everyone reports on their progress towards the goals? Or should the work attend, i.e., the people assigned to the tickets on the board report on how the work defined by those has progressed towards the goals? Both approaches have merit as well as issues. I've observed that "people attend" often derails the standup into storytelling, while "work attends" bears a certain potential for derailing into technical deep dives.

Whatever it is, the standup should always be about progress towards the goals, and what has been done since yesterday, what will be done until tomorrow, and if any support is needed. Not more. If anything, standups should be crisp.

Tags: work

Immaturity in ... Software Developers?

2022-01-29 — Michael Haupt

Here's an article on five signs of immaturity in software developers. In case you're expecting me to go on a rant about how bad some software developers are, expect disappointment. If you're a software developer, please do read it after all, and reflect, but I'm about something different.

Such signs of immaturity can show in all functions, and I'm trying to abstract from the software developer function here. To recap from the article, the five signs are these:

  1. Being a Tech Zealot

  2. Lack of Team Focus

  3. Neglecting Business Problems

  4. Rejecting of Best Practices

  5. Happy Path Focused

Frankly, you can apply all of these headlines almost unchanged to other functions - managers, PMs, controlling, HR ... you name it.

The sole and obvious exception is point one, "being a tech zealot". But the abstraction is easy. If, at any point, you think you know it all because you have your golden hammer, there you are. Avoid losing your curiosity.

Tags: work

Silence Means ... Agreement?

2021-12-25 — Michael Haupt

Have you ever used this approach for decision making in group settings? "OK, that's the question. Let's decide. Yes or no? Silence means agreement. 3 ... 2 ... 1 ... thank you, we have a decision, it's a yes."

Some months ago, I had spoken with a product manager in the org of which I lead the engineering side, and expressed some discontent with some not-so-nice UX that had ended up in production. The PM and I then mused a bit about how more attention to detail could be instilled so that rather obvious UX glitches don't end up in customers' faces. I like to refer to this as taking pride in one's work, and having a sense of honour as craftspeople. We ended up discussing about how to have shorter feedback loops, by pulling up the "latest version" of the experience at all possible occasions and collecting quick feedback.

Since, I'd thought about this some more, and would like to share one thing that happened a while back in a meeting with one of my teams. There, the discussion was whether to assume responsibility for a piece of functionality that's currently stewarded by another team but that would make much more sense in this team. The question came up, some people expressed agreement, and then - silence.

The usual pattern is to assume silence means agreement. That's easy, right? I turned it around, because taking responsibility for a piece of functionality means some more work, and potentially interruptions if something is really off. So I made clear in the meeting that "silence means disagreement, so please speak up with a clear YES now or raise your concerns" - and lo and behold, some concerns were raised. These were subsequently settled, and the story could continue.

So much for the excursus. The idea, abstracted from the example scenario, is to pull in active consent rather than consent by silence, and thereby to encourage dissent.

Applied to the UX-glitches-in-production issue, if anyone feels that the experience we're about to release to the users is not good enough, they should speak up. If the entire team expresses active buy-in, they're also collectively accountable.

It's also a pretty egalitarian exercise: no matter who speaks up and mentions concerns, these concerns will be important to address. Whoever raises their voice, they're not speaking from a position of power, but from one of empowerment. Everybody in the team is empowered to deliver good UX.

This should not be misused as a tool to enforce consensus. Some concerns may be valid but not urgent. They can be addressed later. But it is important to identify concerns that should block a rollout and address these. It's also necessary to have a foundation of trust, because otherwise expressing active buy-in can be abused to weasel out of necessary and healthy conflict. We don't want yes-people, we want people who are proud of their work.

Try it next time. It can have a surprising effect.

Tags: work

Delegation Poker Applied

2021-12-25 — Michael Haupt

At her school, my wife has taken the responsibility for organising school t-shirts. This job, because it involves many parties - other teachers, members of the school's friends' association (sponsoring the shirts), and, oh my, parents - is an absolute magnet for bikeshedding discussions. What shirts to buy - organic / high quality / cheap but oh please don't ever cross that absolutely red line price tag or else -, what colour to use - oh please, my kid doesn't like green, never mind everybody else -, and so forth. You get the idea. (Perhaps you've been part of such things. Don't do it again please.)

Anyway. Because she was worrying about how to go about the discussion, I gave my wife a brief intro to delegation poker, and given that she has so far had all of the responsibility and work, but everybody else has just been flinging requirements around without showing the slightest sign of will to contribute, the consult model ("I will consult and then decide") seemed absolutely justified. My wife was relieved. (Green it is.)

Tags: work

Difficult People on Software Projects

2021-12-11 — Michael Haupt

Slightly tongue-in-cheek, here's a guide on How to Deal with Difficult People on Software Projects. Do you find yourself in there? (I do find myself, here and there.)

Tags: work

Silence in Meetings

2021-12-05 — Michael Haupt

The key point in this piece on silence in meetings is that silence has value, and should be used. It's a very common situation - I bet we've all observed it at least once - that meeting participants hasten to make their point, people will constantly talk over each other, eager to air (not: share) their views - there isn't enough listening in many meetings, and not enough time to process. It's ironic because meetings are supposed to be productive.

I'm writing this from the perspective of an introvert, I'm not very good at processing lots of input on the spot. I need time for that. Your mileage may vary, considerably so. Still, creating and sustaining a work environment where leveraging everyone's capabilities is an actively pursued possibility is an act of inclusion. Where there is inclusion, diversity will follow (here: diversity of thought and insight), and that's supposedly a Good Thing, right?

The article makes many excellent suggestions of a very practical nature, and I can relate to many of them. I particularly like the one where the usual take on silence as an expression of agreement is turned around. Requiring everyone to actively express consent rather than dissent is a beautiful pattern to bring out all the opinions in the room, even from those who speak up reluctantly. (I've tried it. It works.)

Dare more silence!

Tags: work

Code Pwnership

2021-11-08 — Michael Haupt

code pwnership: being in charge of a code base multiple clients depend on, having exclusive commit and release rights, and totally refusing to fulfil requests or consider pull requests.

Tags: the-nerdy-bit, work, hacking

Coaching and Mentoring, and Boundaries

2021-10-18 — Michael Haupt

When is it "OK" to not coach, in what is supposed to be a coaching session?

Many first-time coaching clients come to their first coaching session with the desire to "get your advice on this", "pick your brain about this", or "hear your opinion about this". This indicates a desire for mentoring rather than coaching: a coach will serve the client by being a catalyst for the client's thoughts, a mentor will share experience and give advice.

Since coaches are expected to stay in their role, one possible reaction to a client coming with a desire for mentoring can be to gently point them towards mentoring providers, or to help them find a mentor that suits them. It's also possible to convert the session into a mentoring session on the spot, if the coach is also capable of mentoring the client in their field of interest.

Both of these may be missed coaching opportunities. Given this is about first-time coaching clients who haven't had prior exposure to coaching.

What I usually do when a first-time client expresses a desire for mentoring is to clarify on the spot what the coaching/mentoring difference is, and that we could also have a mentoring session, "but rather not now, this is a coaching session". The client, being aware they haven't got any coaching experience, will usually agree to give it a try. In the overwhelming majority of cases, that works very well.

One approach that has led to very nice and sometimes surprising outcomes is to turn the "I need mentoring on X" situation into a coaching situation by shifting the focus from the client's immediate desire ("mentoring") to the situation ("X"). Diving deep on the "X" will typically reveal the client's real needs - the needs underlying the expressed desire. Once the perceived need for mentoring is replaced with the actual need coming from the situation, coaching gets into full swing.

There can also be cases where the ethical boundaries for coaching need to be invoked. When it turns out a client actually needs counselling or therapy, e.g., because their situation looks more like a full-on burnout, it's better to err on the safe side of not coaching on that topic. (I'm not a qualified therapist, so I must not attempt to do something about a burnout, lest I cause more harm than good.) When that happens, a coach can still point a client to the right places - often, companys' HR departments can establish contact with professional counsellors or therapists.

While this ensures the coach doesn't violate the necessary ethical boundaries, it can still give the client a feeling of being pushed away if the coaching session is cancelled on the spot. One thing I usually try in these (rare) cases is to ask the client if they had any practical topics (time management, for example) that somehow have to do with the burnout, but aren't the core topic. That way, the client can still get tangible value out of the session.

Tags: coaching, work

Feedback Better Be A Two-Way Street

2021-10-02 — Michael Haupt

We're using feedback at Babbel - it's a power tool to improve and reinforce, with special regard to individual behaviour and relationships. But is it enough?

There's positive and negative feedback. For the latter, some like to use "constructive", and that's a misnomer used out of fear of using bad-sounding words: positive feedback should also be constructive, after all. If you want to avoid using adjectives, use "praise" and "criticism" instead, as long as you stay constructive in either case.

The process for giving feedback is to share your observations, the impact it had on you, and maybe what you'd like to improve or be amplified. It's important to stick to observable behaviour no matter what, because that's literally the only thing you can know for sure: what you observe and what impact it had on you. You typically know very little about the other's motivations and values, so you should refrain from making assumptions and judgments - don't interpret, observe.

It's a power tool because it allows to share, in a safe way, what things should change, and what things should be reinforced. Good things can come from it if it's used well. However, I think there's a problem with feedback in this pure form.

Quite bluntly, feedback's a one-way street, especially when it comes to negative feedback ("criticism"). When I give such feedback, I share my point of view, my issues with someone else's behaviour, and my desire for change. I give the receiver of the feedback a chance to build some empathy with me, to understand me. It's all about me me me - in this framework, I don't get to building empathy with the other, I don't get to understand what made them behave the way they did. Instead, I put my expectations in the other on a pedestal: Here's my feedback, now take it and act accordingly.

Babbel's company purpose is "creating mutual understanding through language". The emphasis is mine - can you see why? Feedback as used above is, as mentioned, a one-way street. I want all the empathy but I don't give any. I expect all the understanding but the framework doesn't expect me to understand anything. The understanding is not mutual.

It's easy to jump to conclusions and make rash judgments, and to give feedback in correct form but from a perspective of a judgment already made. I firmly believe that very few of us humans walk the Earth with the intent to be a nuisance. Perhaps the other did that annoying thing because they're lacking a crucial bit of information. Perhaps that's a piece of information I can give them. How would I know without asking?

I think that a very simple tweak to the feedback framework will suffice, and it won't take any of the value away from feedback. It's as easy as adding a little bit of inquiry to the playbook: first, you share your observation; second, you describe the impact it had on you; third, you express your desire for change or reinforcement; fourth, you inquire about what made the other act in the way you observed. This last extra step opens up a conversation, instead of stopping right there. The inquiry can be very simple. It's best to avoid the blunt "why" because that can sound a bit confrontative, but there are better options: "what made you ..." goes directly to the other's motivations, "to what end did you ..." asks for utility and reason, for example.

The effect of this little tweak should be positive. It changes the feedback situation to a two-way street, to a situation where mutual understanding and empathy can be built. It's how we should show up.

Tags: work

The Build Trap

2021-10-02 — Michael Haupt

Here is a brilliant article on the build trap - that state you can end up in when you measure success in output rather than outcome. The article is full of wisdom relevant for OKR setting and measuring success, and it’s a healthy dose of customer value centricity for everyone who’s “just” thinking about that next commit, that next merge, that next rollout.

In a nutshell, having impact should be valued over producing artifacts and delivering features. This thinking can apply at all levels of scale.

Using JIRA tickets and epics to quantise work? Consider expressing them as user value increments and user-observable acceptance criteria rather than technical to-do lists.

Setting sprint goals? Consider framing those as value-adds rather than “deliver X”. (The value-add notion opens a path to better measurability.)

Formulating OKRs, at any level of the organisation? Choose KRs that express actual value delivered rather than sheer usage metrics.

Inside the build trap, every line of code committed, every feature rolled out, are successes. If they end up not adding any value anywhere on the user side, they have a blinding effect.

Tags: work

Autonomy and Silos

2021-09-16 — Michael Haupt

Following up on a recent note on autonomy and accountability, here's an article with a provocative title saying that "autonomous, self-organizing teams don't work". Two key quotes:

In an organization guided by the concept of interrelatedness, when another team comes and asks for help, we say “Yes,” because we’re working for the same organization. Whereas the default answer in Scrum is, “No, put it in our backlog.”

And:

Responsible teams make good decisions and function in a healthy way within the larger organizational ecosystem.

Indeed, no team works entirely on its own in a sufficiently large organisation. Teams insisting on doing that are silos, and that usually doesn't help the greater goal of the company they're part of. I'd even go one step further and scale the two quotes down to individual team members. No member of a team works in isolation, maximising their own productivity - it's always about maximising throughput for the team. Individuals can also be silos, and that's just as unhelpful as siloed teams or organisations.

In other words, "I just want to be left alone and do my work" isn't an acceptable stance - it's always your work in a greater context.

Tags: work

Dreaming, Goals, and Coaching

2021-08-22 — Michael Haupt

In a recent leadership training, the trainer recommended the book Rethinking Positive Thinking by Gabriele Oettingen.

It's not strictly a necessary and important read, unless you have a very specific interest, and even then, the value is limited. Here's why. The book's gist, put very bluntly, is that, in order to realise your dreams, you have to be realistic about the obstacles and make plans for working around those. Well, go figure - that's about as common sense as it gets. Snark aside, the book is happily not one of those wordy self-help tomes, but provides an overview of all the empirical research the author has conducted to prove what looks like a truism true. That's good: the psychological effects of imagining obstacles and thinking them through are a thing, and they spawn more determination. Oettingen then also introduces a small but powerful framework called WOOP (wish, outcome, obstacle, plan) that can be used to do the mental exercise, and gives examples of its application.

So, while its gist can be summarised in a paragraph, the book extensively describes the numerous studies and thinking journey. This is the value a reader can take from it: if you're interested in empirical study design, it's a treasure trove. The value is limited, though, as the book stays at the storytelling level and doesn't describe the study setups with the statistical rigour that would be needed to unleash full social sciences thinking.

The book did have some unexpected value that emerged when I processed it, post-reading, in the context of goal setting and career development conversations. In fact, something bigger may yet emerge from that (stay tuned).

Reproducing an idea from the book, dreaming is a substitute for doing, from which short-term happiness ensues, but no action and no change, and consequently less energy and momentum to realise the dream. This reminded me of the importance of the "accountability exercise" in coaching - i.e., the part where the coach works with the client to define and commit to actions and check-ins. In other words, generating an insight is not enough: what actions follow from it is important.

I have since applied Oettingen's WOOP framework in coaching, using it right there, or proposing it to clients as a mental tool for getting more clarity about goal setting. This had a good impact both in the sessions and during the periods until the next check-ins and follow-ups. In the greater context of goal setting and career development, it can be a valuable tool to work towards better goals with more clarity, probably even towards structured approaches like SMART goals and longer-term vision manifestos like V2MOM documents.

Dreaming is good. Taking the obstacles into account helps devising and implementing the plan. What's not to like?

Tags: books, coaching, work

Autonomy, and Micro-Management

2021-07-12 — Michael Haupt

It's a good thing for a team to be autonomous. Micro-management doesn't help in most cases, and teams typically know how to go about the job if the objectives are clear. Autonomy does have to come with accountability though, otherwise it's just anarchy. Mistaking being held accountable for being micro-managed is indicative of "leave me alone" thinking, which isn't very healthy - that's just not how it works. It is admittedly a fine line, and avoiding to be mistaken that way is a matter of trust, which needs to be built from the ground up. Patrick Lencioni really got this.

Tags: work

Delegation Poker

2021-07-04 — Michael Haupt

A frequent cause of disconnect between (autonomous) teams and management is when teams are presented with a decision the need for which they agree with, but that they think they weren't properly involved in. This is usually the case when a team doesn't live up to one key expectation of autonomy: actually taking decisions, e.g., on improving their processes and then implementing them. If a team is unable to arrive at a decision, the natural consequence is to escalate that to the management level, because we cannot allow ourselves to be held up by indecisiveness.

If management is then doing its job, it still needs to be clear how the decision will be made, to avoid putting anyone off. Is the manager simply going to decide and tell the team what to do? Will the manager consult with the team and then transparently decide? Will the manager delegate the decision back to the team? There is a wide spectrum of possibilities, and to avoid frustration, it is important to agree upfront how a decision is going to be made.

Delegation Poker is a "serious game" that can be played to decide, before a decision is made, how it will be made. It's really smooth as long as everyone agrees on the ground rules. Delegation poker operates on a spectrum of seven ways of decision making, ranging from giving full direction to full delegation. To agree on how the decision will be made, the involved parties each play a card describing their preference. If the cards are one step apart, the lower number wins (this leans towards more managerial influence, in the spirit of getting decisions taken and things done). As long as the cards are more than one step apart, everybody is expected to explain why they've chosen that card, and then another round is played. With reasonable people, this helps to arrive at conclusions about how the decision is made, and then it can finally be taken.

Tags: work

Best Practices

2021-06-27 — Michael Haupt

This article makes some excellent points about "best practices". It actually proposes to be thoroughly agile about things: keep evaluating, improving what doesn't work, and amplifying what does. Keep your eyes firmly on the value you want to deliver. It has to be noted that it takes some experience to implement the "way out" the article mentions - if you're too inexperienced (as an individual, or as a team) to see right through cultish best practices, you may also be too inexperienced to see which best practices are genuine. It's best to talk, get involved, network, discuss. Openly. Use data as evidence, and make decisions based on evidence.

Back in my academic days, I had frequent encounters with Stefan Hanenberg, who set out to investigate some dearly held beliefs in software engineering, for instance "static typing makes software better maintainable". Here's the actual study.

Tags: work

Respect People, Not Titles

2021-05-12 — Michael Haupt

Here is a good collection of "non-technical skills every developer needs". I'd like to expand a bit on no. 5, "respect people, not titles".

You can come right out of university, co-found a startup, and have a title like CTO, CEO, VP, ... in a company of 20. You can also work in an industry for decades, and eventually arrive at a title like CTO, CEO, VP, ... at a company of 20,000. The titles mean very different things in both cases as far as experience is concerned. They mean rather similar things, however, in terms of what you're responsible for.

That's the deal. The title describes a responsibility and implies what you're accountable for. And that is true for titles like "Engineer" or "Senior Engineer" as well. All these titles describe a role, they describe what expectations you're typically going to face. Nothing more. Specifically, a "grander" title doesn't mean the person holding it is a better or worse person per se.

No one should assume people holding "grander" titles automatically talk from a position of power. When your manager, CTO, CEO uses the app your company sells and finds and reports a bug, that doesn't mean this bug deserves special and immediate attention just because of who raised it. It's a bug, and needs to be analysed and prioritised just like any other bug.

If anything, "grander" titles should come with more humility, and a sense of serving a greater scope - and, often, a larger group of people.

Tags: work

Meetings are Work

2021-05-08 — Michael Haupt

Reading these two postings about time management (which is a hot topic for me) and tooling for that, I can conclude that I like the approach very much.

There was one of those cringeworthy moments though when I read this passage (emphasis mine): "Once I became aware of how much time is taken by meetings, I developed a strong aversion against accepting them. I realized how they cut my day into small blocks that are mostly not even worth starting something valuable. It's important to know when you have time to do your actual work."

This was written by a software engineer. I acknowledge how much engineering work - "coding" - benefits from clean, hard, sheer focus and how much it suffers from context switches. Badly scheduled meetings in the middle of what could otherwise be focus periods impose context switches and harm focus. Point very well taken.

Having said that, I disagree, fervently so, with the take this engineer has on how they regard meetings, and how they have decided to feel about dealing with invitations.

There isn't a clean-cut dichotomy between meetings and "actual work". There just isn't. Meetings are work. It's a different kind of work that happens in meetings, granted, but it's still work. Refinements and retrospectives are typical examples of meetings where engineers do important work - actual work - that's not coding.

Meetings aren't the real problem. The real problem is when someone attends - or is made to attend - a meeting where they neither bring value nor take any value with them. I know there are too many of those.

This engineer's reaction is to develop a strong "aversion against accepting" meetings. That's a rabbit hole we shouldn't allow ourselves to go down. The philosophy shared in the two postings has, at its core, the idea of owning your time. Perfect! Now, that ownership is best expressed by defending it in a constructive way, rather than going all grumpy and blocking all of the calendar against meetings. If there's a bad meeting, speak up. Point out how you're neither getting anything out of it, and how you don't feel you can add any value there. If the meeting can't be improved, there should be an agreement that you no longer need to attend.

Often, meetings have an unclear purpose, or a stated purpose that's not lived. Both of these are valid points to speak up about. No one likes to waste time.

Tags: work

Hustle Culture

2021-04-09 — Michael Haupt

This piece on "hustle culture" is relevant. Many of us have been working remotely for a long time now, and our take on integrating the non-work and work parts of life with each other has gotten more important with that. What the article underlines is that it's important to be conscious of this integration (or separation, for some - your mileage may vary). In any case, in summary, take time for yourselves.

Tags: work

Negativity Traps

2021-03-21 — Michael Haupt

Turns out there's a framework and tool for honouring other people's intentions, and it's an extended version of Hanlon's razor ("never attribute to malice that which is adequately explained by stupidity"). The extension factors in, amongst others, "misunderstanding" and "other probable causes". To quote:

The underlying assumption that the other person is acting out of bad intention can shut down all possible communication. The negativity trap can prevent us from reaching out to the other person.

The concept of a "negativity trap" is key. Once we're set on our negative perception of someone, that's that, and we'll only look for signs to manifest that view, but ignore any others. Bad idea.

In other, somewhat related words, translated from here:

Being positive makes you vulnerable, the cynical critic is supposedly stronger. However, they only destroy. They do not build. They are not creative, are without spirit. Criticism is good, judgment must be, but we will be saved from negativity through the principle of putting saving before judging.

Tags: work

Code Reviews

2021-03-01 — Michael Haupt

I don't agree with the falling in love part here, but agree emphatically with all the bits about code reviews. Especially in remote work times, overcommunicating on the purpose of a pull request is important: any question the reviewer might have that takes time to answer effectively slows down progress - and keeps the work that's almost done from being delivered. The flow must not stop. Please, always document your pull requests in as much clarity as you think might suffice and then some.

Tags: work

Getting S... Done

2021-01-10 — Michael Haupt

I don't want to ever get shit done. If I do, what is it, then, that my customers or other stakeholders will get from me?

I know, I know, it's "just a figure of speech" - OK. So is getting things done, or getting stuff done. Why use faecal terminology when there's something better, and more apt?

How do we really think and feel about what we do, and how can we adequately express that?

Tags: work

Cross-Functional Teams

2020-12-30 — Michael Haupt

At work, I serve the engineering side of the "learning experience area" (LXA), which is in charge of most of the aspects of actual language learning as our customers are facing them. There are three XAs, each of which is co-led by a product and an engineering person.

My product partner and I have established a "The XA is the team." motto. It's the headline for how we are thinking of LXA as being strictly more than our respective (reporting) orgs. It means that the notion of "team", i.e., group of individuals that work towards one shared objective, should very explicitly be understood as one that spans reporting hierarchies, or cuts across them. You can think of this as a view on teams as proper cross-functional teams.

What does this mean concretely? Take one of my engineering teams that is currently doing a technical overhaul of the lesson player (a core piece of the learner experience). The team consists of (in alphabetical order, to emphasise that everyone contributes equally) back-end engineers, a designer, a didactics project manager, an engineering manager, front-end engineers, a mobile engineer, a product manager, a QA engineer, and a test automation engineer. Many of these people aren't in my or my product partner's reporting org; they're in different organisations, and yet they're part of LXA because they contribute to the work LXA is delivering. In fact, the team would simply be incomplete without these folks, and their input is crucial to the team's success, as is the input provided by the engineers.

The point is, reporting lines have more to do with functional clustering and people management / career development than with team and work organisation. The latter is strictly more important for company success, so being pragmatic about it is key. Thinking of teams only as reporting structures can easily lead to silos, politics, and turf wars (to quote a book title and give a reading recommendation) if egos overrule mission and alignment. Conversely, the factors that should drive work organisation are priorities and capabilities - and each team should ask itself whether they're working on the most important thing for them right now.

This is true at all levels of "team", including leadership, of course, and even the entire company. One consequence of this view is a strong commitment to getting the important things done and helping each other out across reporting organisations. If, say, another XA is missing engineers with a certain capability but needs to contribute to a high-priority OKR, and my XA is working on items of lesser priority, it's natural to think about supporting them by asking engineers in my org to help out "over there". After all, we're here for the success of our customers and thereby the company, not for the success of our immediate surroundings. Global optimisation usually beats local optimisation.

I'll give another, perhaps surprising, example: hiring.

There is a hiring team involved with filling a role. For hiring a mobile engineer (since that's currently on my mind), it consists of (again, in alphabetical order) engineers who conduct technical interviews, engineers who review coding challenge submissions, a hiring manager, a people and operations colleague supporting the contract and onboarding, and a recruiter. Again, everyone contributes, and the objective cannot be achieved if any one of these members stops contributing. What is the objective? It's twofold. On the one hand, the role needs to be filled quickly with the best possible candidate so that the team in need of the role, and the company as a whole, are set up for success. On the other, the candidate should get a good impression of the company in any case - regardless of whether they're hired in the end or not.

What does this mean? Hiring is a project just as any other project, and it requires a team that goes about its work with great dedication. This implies some priority juggling. Should I, as an engineer, focus on the work needed to complete that JIRA ticket, or on reviewing that coding challenge? Should I, as a hiring manager, focus on screening those 30 CVs, or on straightening the work processes for that one team in my org? The answer is, as usual, "it depends", but it is important to keep the work flowing in all of these areas.

In my book, hiring usually takes priority, simply because being fast at it means that I'll be able to work with meaningfully complete, and hence more powerful, teams sooner, which is good for the company - and the customers.

Tags: work

Responsibility, Accountability, Empowerment, Autonomy

2020-11-22 — Michael Haupt

During a recent discussion at work about empowerment and autonomy for engineering teams, the topic of responsibility came up, and its relation to accountability. Some notes on this.

From my perspective, if any of the teams in my organisation make a tech choice, I'll still be accountable for what happens thereafter thanks to what the HR system says about me. :-)

The accountability thing is where empowerment and autonomy get interesting. A team may be responsible for a decision, which is perfectly fine. They're also accountable for the outcome, but so is their entire management chain, to varying degrees and in varying ways. Accountability always affects someone else too.

Imagine (content warning: highly artificial example ahead) a team inadvertently making an irreversible (I said it's artificial - this is for illustration) tech decision that turns out to have some hefty consequences in production, leading to considerable performance impacts for users. Those can be addressed by provisioning many more cloud cores. The team's manager will have to explain that to the department director, who will have to explain it to the CTO and Finance. The CTO needs to explain it to the CEO, who will have to explain the cost explosion to the board. Accountability all the way.

Responsibility is for making the decision. Accountability is for bearing the consequences, and explaining them.

This is why pure autonomy - as in "leave us alone" - can be a little bit dangerous. It's best to invest some energy in building a good and transparent relationship with those carrying the accountability.

Imagine whose lives your decisions may have an impact on. Hint: your manager is among them. ;-)

In delegation poker parlance, things that bear a certain risk shouldn't be carried out in "delegation" mode. "Advise" and "agree" would work better.

Tags: work

Decision Making

2020-11-15 — Michael Haupt

Decision making is such an important discipline, and it's hard to get it right. It's definitely one of my struggles. This piece is helpful in that regard as it sheds some very clear light on the principles behind it. One key takeaway is that the HiPPO pattern (highest-paid person's opinion) can skew decisions because it leads to disfavouring expertise in favour of plain power, even if the proverbial highest-paid person does not intend that at all. For example, if your boss, or your boss' boss, or someone else "up the chain" has a bit of feedback on The Product, that doesn't necessarily make it a priority one issue. It's just feedback, and you're in charge to do with it what's right.

Tags: work

Data Driven

2020-11-08 — Michael Haupt

What does it mean to consider yourself and your organisation "data driven"? I like to use that term carefully - if data drive you, they're in charge of what you do, and it's nothing but sheer numbers that determine your every step. What about human intuition, a decent share of gut feeling? I usually prefer to use "data oriented" instead. Data are but one, if crucially important, aspect for orientation in problem and solution spaces. Data aren't knowledge. They aren't expertise, let alone experience. It requires sensemaking to let data guide what to do.

Here's a podcast episode that expands on the topic. It covers a fair share of decision making, and why decisions may take long sometimes.

Tags: work

Code Ownership

2020-11-01 — Michael Haupt

Recently, the notion of "code ownership" (as in: this team owns that code) came up once more. In this context, "ownership", in my humble opinion, is a misleading concept.

Who "owns" the code? Any individual engineer or team? That would mean that if they move to another team or organisation within a company (or leave) they can take the code with them. Nope, won't happen. You may think this is nitpicking, but words have meanings after all, and "I own this" is a fairly strong statement that brings with it a lot of confidence and entitlement. If you own something, technically speaking, you can just tear it to shreds when you feel like it. (Who has never wanted to do that with a piece of code refusing to be bugfixed?) If you own something, you can also easily say "no" to anybody else's request to do something with it.

Let's be clear: the owner of a company's proprietary code is that company. Not some team or individual, but the company.

What then?

How about "stewardship" instead? A steward has very far-reaching rights over the properties they've been put in charge of by the owner. They act in the sense of the owner, out of a deep sense of responsibility and in good spirit, protecting the property from harm but recognising the needs of stakeholders. See how that's different and more collaborative?

(And just to be clear, a certain Denethor is not a particularly good role model.)

Tags: work

The New Normal

2020-11-01 — Michael Haupt

With Covid-19 rates on the rise everywhere, and the German government imposing considerable restrictions starting this coming week, there is again an increased tendency to refer to the situation we're in as the "new normal". I refuse to call it that - it's still exceptional, we're dealing with a situation we have never faced before, and there is nothing normal about it. We're coping, not settling in. A "new normal" will eventually emerge from our experiences during coronian times once we are in control of the pandemic rather than it of us, and that we have a good chance of shaping. This podcast episode sports a bit of musing around this topic.

Tags: work

Questions for 1:1s

2020-09-27 — Michael Haupt

Here is an inspiring piece about questions for 1:1 meetings. It's mostly about meetings between managers, but I feel that many of the questions are also usable in settings involving managers and non-managers.

Tags: work

Engineer to Manager

2020-09-20 — Michael Haupt

Switching from engineering to management is an oft-taken step, and many think of it as "being promoted to management". I disagree - making that move means doing a different job. It's more like switching tracks than being promoted along your current career trajectory. YMMV, of course, and there are always cases where you still do a fair share of engineering, but letting go and learning new things are inherently part of this. A colleague brought two texts to my attention that sum up my thinking quite nicely. There's also a podcast episode that I highly recommend; it's about Patrick Lencioni's (excellent, as usual) book "The Motive" that discusses the fundamental question: Why do I want to be in leadership?

Tags: work

The 1x Programmer

2020-09-13 — Michael Haupt

Have you heard about that "10x programmer" thing? Most of it is nonsense in my (not quite so humble) view. This article has a lot of interesting remarks from the perspective of a "1x programmer", which I have a lot more sympathy for.

Tags: work

Ethics at Work

2020-09-06 — Michael Haupt

Some months ago, Tim Bray left Big A, and it serves to show that what's to be considered ethical at work cannot be defined by the corporate entity at hand. Ethics is a, hmmm, slightly more universal concept. Remember that when taking compliance trainings.

Tags: work

Work in Coronian Times

2020-08-30 — Michael Haupt

A while ago, a tweet made the rounds that, no matter if it's authentic or not, completely matches how I feel and think about work in coronian times. I'll leave this here without further comment.

Tags: work

Technology Hypes

2020-08-29 — Michael Haupt

This piece on Why We At Famous Company Switched to Hyped Technology is pure gold.

Tags: work

Deadlines

2020-08-29 — Michael Haupt

Committing to a fixed set of timed releases a year, half year, or quarter in advance does not work well. Here's how.

Tags: work