Haupz Blog

Getting to Measurable Outcome

Recently, I had written about the difference between outcome and output, and how “To what end am I doing this?” is the kind of question to ask to move from describing output to describing outcome - which is the right frame for describing goals.

In the true spirit of SMART goals, outcome should also be measured. There are two kinds of questions to get from output to measurements.

From the output perspective, what does it mean to implement the todo list? Asking “What change do I intend to achieve by generating this output?” implies that there is an observation that I’m currently making, and I want it to be different. Expressing that difference points to a possible measurement.

From the outcome perspective, I can ask “How would I notice the intended outcome is achieved?” to get to a similar response about the difference it makes.

The former question will likely yield measurements of a more internal nature, closer to the output. Conversely, the latter will more naturally lead to measurements closer to the customers the outcome is impacting. Both of these have a lot of value.

The necessary connection between both can be used to apply reality checks, too: if the internal measurement indicates success, but the external measurement doesn’t, I must’ve missed something. Such an insight is invaluable, too, because it helps to develop a deeper understanding of work on customers.

Tags: work

Engineering Managers' Rights

Engineering Managers (at all levels) are in an interesting position as they have to represent their team’s and team members' interests to the company, and the company’s interests to the team. This has always been a challenge, and the past few years - with increased demand for remote work possibilities - have intensified the challenge. The need for frequent application of non-technical, so-called “soft” skills (which are very hard) has significantly increased. In addition, a tough job market has let focus on individual contributors' interests grow. We cannot let attention to managers' needs slip.

Two articles describe an engineering manager’s “bill of rights” (and responsibilities) and some observations on what specifically contributes to managers' wellbeing at work. There is a lot of overlap: transparency, fairness, clear expectations, specific development opportunities, visibility, and so forth.

Food for thought.

Also, let’s not forget there is a corresponding engineer’s “bill of rights” (and responsibilities), which inspired the former of the two aforementioned articles.

Tags: work

Output and Outcome in Goal Setting

What is output, what is outcome? The difference is maybe a bit subtle at first, but of fundamental importance, and makes a lot of sense once you “get it”.

When setting goals, one will like to describe them as “things achieved”, and will write down items such as “implement this feature”, “update that library”, “migrate yon product to another infrastructure”, and so forth. These make sense, right?

Only that they’re not really achievements. They’re activities that are completed. Boxes ticked. “Things done”, rather than “things achieved”. The achievements are the things one would answer when asked “to what end do you do this?”

Things done are output - they have no value of their own. Things achieved are outcome - they have value.

A plain example: the lightbulb in your home office room is broken. You replace it so that you don’t have to work in the dark. The replacement is the activity, the output. Not having to work in the dark is the achievement, the outcome.

One should formulate goals in terms of outcome - it’s usually better to express them in terms of the value they add. Knowing that value and the scale on which it lies has the extra benefit of yielding a better measurement for success than “done / not done”.

So if you catch yourself formulating goals as completable activities, ask yourself: To what end am I doing this? What value do I hope to add?

Tags: work

Growth Mindset Across Seniority Levels

Andreas Kling here shares one of the most fundamental differences between junior and senior thinking:

Junior mindset: This language/framework is part of my identity.

Senior mindset: This language/framework is part of my toolkit.

This is not about junior and senior career levels, although there may be an overlap: I’ve seen a lot of junior mindset in people in “senior” roles when it comes to being fixed on tools, frameworks, languages, approaches, …

Having a growth mindset - I believe that’s what makes the difference.

Tags: work

The Alert That Cried "Problem"

Getting alerts right is hard. If they’re over-zealous, on-call folks will be woken up in the middle of the night for no really good reason. If they’re too hesitant, things go awry for too long before anyone notices.

It's easy to fall for configuring too many alerts "just to be sure". In such cases, some on-call supporters may implement workarounds that will wake them up only if the alert isn’t gone after 5 minutes.

But that kind of thing shouldn’t be necessary. In case of a serious outage, 5 minutes can be a lot of time. Any alert should be serious.

If that's not the case, there is a glitch in the system that needs to be sorted out. If the alerts are bogus, they should be changed, and if there’s an issue in the software or infrastructure, that needs to be fixed - and there has to be a solid idea of why it happens before measures are taken.

Here’s a set of pragmatic guidelines for alerts “that don’t suck” (it came to me via my former eBay buddy Mitch Wyle). Maybe one starting point.

Tags: work

Tester Impact on Quality

Does having testers around make quality worse? Maaret Pyhäjärvi has written about it very thoughtfully. She concludes that yes, “having testers makes quality worse if developers let go of testing they are doing now”.

This is an excellent point. If testing is only the testers' job, and developers stop caring about it, quality will suffer. In other words, in an environment where there is a rigid and narrow 1:1 mapping from job title to expected tasks, and where people are all too happy to pushing tasks away that sound like others' job titles, this prediction will very likely come true.

If there’s a tester on a team, their job isn’t the testing, just as a developer’s job isn’t writing code. This only makes sense at the most basic level. In a team, real strength emerges from interactions and collaboration. So does quality.

Consider a job title not as a bunch of tasks, but as a certain perspective on the work at hand. Consider a team’s work not as transactional episodes, but as continuously combining those perspectives. The developer brings the engineering perspective, the tester brings the testing perspective. Both pursue quality. Imagine a pair programming session wherein a developer and a tester work together. This scales for other roles found in teams.

Pursuing software product development properly implies that quality is a constant concern for everyone. Having testers around, then, will improve quality by virtue of taking their perspective seriously, rather than regarding them as testing service providers.

Tags: work

GDD

One good and simple framework for retrospecting on something is good - difficult - different (GDD), supposedly coined by Marshall Goldsmith (I couldn’t find the primary reference).

When reflecting a situation, event, or anything, you ask yourself: What was good about it? What did I find difficult about it? What should be different about it? (A variation on the latter one is: What would I do differently next time?)

I’ve found this format helpful also in situations where things have gone really, really awry, some firefighting is needed, and a blame-free and non-judgmental analysis is necessary after the dust has settled. One may wonder what it could possibly be that would be good about a really bad situation - but keep in mind that the exercise should be run after the dust has settled: the process of discovering the badness and mitigating it is what’s under observation, not the bad situation in isolation.

In other words, if sh*t hits the fan, clean up the mess first, then sit down to analyse. There’s usually something to learn in there. Being able to dissect things in a structured way helps with that.

Tags: work

Agile KPIs?

What KPIs make sense in agile environments? The linked article takes a clear stand: it’s a rant against the “measurability myth”, and the only metric that matters in the end is customer satisfaction (which is hard to measure, but NPS helps to a degree).

The opening statement boldly claims that KPIs and agile just don’t mix well. Take velocity based on story points: it’s not a performance metric, because it measures sheer output. The problem with story points is that they’re not measurable quantities, but qualitative ones that even vary in their meaning across teams.

Real KPIs measure outcomes instead, i.e., observable effects of the outcome on the customer.

The article mentions several non-KPIs that are still somewhat worthwhile in agile environments, such as the number of tests written before coding, number of times per week talked to a customer, or team stability and satisfaction. (Elsewhere, I had previously suggested a metric that measures the ratio of things finished over things started.) These can be worthwhile, if only to introspect on the ways of working.

Tags: work

Context Switching and Multitasking

Being human, we can’t multitask. Contrary claims are occasionally made, and while it may well be that there are a few select people who are capable of a higher degree of multitasking than others, the majority of us can’t do this well over an extended period of time, and shouldn’t. It wears us out.

Having said that, very few of us are working on one and just one thing at a time. Instead, we switch between projects, sometimes even between tasks, while they are running simultaneously. Given the previous paragraph, that’s at odds with how we tick.

So is being worn out just a natural consequence of being human, then? I don’t think so. If you would humour some not-backed-by-psychological-research musing …

Context switches are a frequent pain for an engineering team, because every time a switch happens, the team will have to rewire the mental models they are using and working with. While I will be the first to freely admit that avoiding such switches altogether would be great, I also have to face the reality of a team building a next-generation product (that, until ready, can’t be sold) while maintaining the current one (that pays the bills).

What, then, would be a good way of keeping the negative impact of switching between the two at bay? Rather, when is the negative impact the highest? This is when the context switch happens in mid-flight, when the focus is sharp and the work well under way and productive. In such a situation, making a sudden switch to an entirely different code base will be detrimental.

It follows from this that the best moment for switching is when a task is completed. At that point, a decision about whether to continue with the next task in the current project, or whether to switch to a task in a different project, can be consciously made, and the negative impact of context switching will be lower. It will never be zero, because different knowledge and mental models will have to be (re)built.

(Once more, reality may have a different opinion sometimes: if a sufficiently severe bug rears its ugly head in a project different from the one that currently has focus, it will rightfully demand immediate attention. That should be the exception.)

The two models described above resemble different programming models in parallel programming. On the one hand, there’s classic multithreading with its preemptive multitasking model, where the operating system commands when control can switch between threads. On the other, there’s coroutines, which specify yield points, at which context switches are allowed to happen. This is also known as cooperative multitasking.

I believe that engineering teams - unavoidably facing the risk of context switches - would benefit from a cooperative multitasking approach. They will consciously prioritise their backlogs to allow for context switches at points that make sense. This is also relevant for working on bugs, whose appearance on the scene is not predictable. Addressing a bug with less than house-on-fire-incident severity can be scheduled in a smart way, not for immediate attention, but also not too far in the future, depending on its impact and the effort needed to address it.

Ultimately, this is all about giving teams a healthy degree of control over when they perform context switches.

Tags: work

Engagement, Ennui

Here we have a nice piece about engagement at work. It’s written from the perspective of a software engineer, but applies more broadly.

The author calls a common feeling of disengagement “feeling of blah”. The article’s URL names it “ennui”, and I don’t know why the author has decided to not use that wonderfully apt word in the article itself at all. (See here for a more detailed treatment of the term.)

The recommendations are simple. In a nutshell, they involve consciously sparking creativity through curiosity, reminding oneself of the purpose of the work one’s doing, and regarding one’s career as a series of purposefully done steps. Anyone can do this, and it looks like a healthy exercise to put things in perspective.

I might add: if you feel that tinge of ennui, work with your manager. If you can’t see why and how what you’re doing makes any sense, your manager should be able to connect it to the why.

Also, if you’re feeling miserable at work (it happens to everyone occasionally), maybe ask yourself these questions (straight from Patrick Lencioni): Whose lives do I have an impact on? and How can I see or measure that impact? The answers could be surprising, and solid reminders about why things matter after all.

Tags: work

WIP Gets in the Way

At some point, I needed something rather important to be completed (in an asynchronous work collaboration with some folks) that ended up not being completed. I was really frustrated, because I thought we had a clear agreement on both the work that needed to be done and the time by which it needed to be done.

That kind of thing always gets me wondering about my communication of expectations and objectives.

And then Twitter dropped another piece of John Cutler goodness in my lap, and it all becomes clearer. Watch him explain, in a 5-minute video, the maze of circumstances and consequences that lead to things that everyone agrees should happen, well, not happening.

So it’s not just my communication, it’s also my and others' work in progress (WIP) level. Addressing that involves emphasising the exercise of mutually providing the right degree of transparency about what keeps everyone busy, and amplifying the feedback loops around that.

Tags: work

A Quote on Meetings

Recently, I found myself in an internet debate with someone over a Peter Drucker quote. Before going into the details, I’d like to mention that Mastodon is really not that different from Twitter; it really is the people that create the atmosphere, not the protocol or owner. Also, the “debate” ended up being pretty one-sided; I found that there really is no point in playing chess with pigeons. Anyway. I’m grateful there’s a block list.

The quote goes like this: "Meetings are by definition a concession to deficient organization[.] For one either meets or one works. One cannot do both at the same time."

Of course, my take on meetings is a very different one, and I don’t appreciate oversimplifications of the matter. The quote, without any context, certainly reeks of oversimplification. All the details of my brief pigeon chess episode aside, I ended up reading relevant parts of the original source of the quote, Drucker’s 1966 book “The Effective Executive”, because I wanted to understand the background. The quote is from chapter 2.

Since the book is about “executives”, let’s establish clarity about whom Drucker is writing. In his words from chapter 1: "Every knowledge worker in modern organization is an “executive” if, by virtue of his position or knowledge, he is responsible for a contribution that materially affects the capacity of the organization to perform or to obtain results." This clarifies that Drucker’s term “executive” includes knowledge workers with the quoted capabilities, not just people from the higher echelons of management.

In other words, the notion of “meeting” applied here is broader than “executive board meeting”. That’s really important to know, because the assumption now is that - slightly simplifying - whoever spends any time in a meeting is wasting time, always, with apodictic certainty. Since I have earlier branded this kind of take on meetings as nonsensical, the quote warrants a closer look.

Here it is, again, including some sentences following it: "Meetings are by definition a concession to deficient organization[.] For one either meets or one works. One cannot do both at the same time. In an ideally designed structure (which in a changing world is of course only a dream) there would be no meetings. … We meet because people holding different jobs have to cooperate to get a specific task done."

In other words, Drucker is describing a utopia and blames reality for not being that utopia. He immediately concedes that, to get work done, knowledge workers need to cooperate: a truism. This cooperation takes place in: meetings. And it is, consequently: work.

Drucker may be a management guru, but that piece, right there, is just plain incoherent. And 1966 is long, long ago. I'm done playing chess with pigeons.

Tags: work

Executive Communication

Executive communication is a relevant skill not just for managers. In smaller companies, individual contributors can easily get some exposure to execs to give them relevant input for decisions. I’d like to share some things about exec communication that I’ve found useful. (I learned some of these the “hard way”, no need for you to do that as well.)

When you approach an exec for a decision, always make clear first thing what it is you need from them, and provide only the most crucial information at first. Don't lose yourself in story telling and providing all the details. You think they're important because they fuel your point of view and recommendation (and you prepared them all, dammit), but they might not be necessary because the value they add might be limited in the context the exec is operating in. The exec will ask if more information is needed, and if you have it ready, that will be great.

I learned this one the “hard way” - in quotes, because the person who was my VP at eBay at the time is an extraordinarily gentle and kind human being. I made the usual mistake: I brought a meticulously prepared slide deck (18 slides or so), with all the important details clearly laid out, a thorough narrative with a really good story arc, only to land precisely on my recommendation for how to proceed on the last-but-one slide. On slide 4, my VP interrupted me and asked the plain question: “Michael, what do you need from me?” I fast-forwarded to the last-but-one slide, and three minutes later things were settled, which involved me going back to one or two of the detail slides at the VP’s request.

The best compliment you can get from an exec when providing input for a decision is "no further questions"; it means they have all the information they need to make that decision. So even if the decision in the end might not be the one you wanted, you'll still come across as capable of preparing the decision making very well. The more senior an exec is, the better they should be at making decisions with incomplete information, and at pulling in the information they might still need.

Tags: work

Google Meet Hardware Support

You know the feeling: you’re in a Google Meet call, have some relevant things open in several browser tabs on the other monitor, you want to push some button in the Google Meet window (or leave it), but you first have to find that mouse pointer, move it over to the right window, navigate it to the right button, and finally, with an exasperated sigh, click it. Maybe there are keyboard shortcuts, but for those to work, you still have to bring the focus to the meeting window first. If only there was a thingamajig that could do the trick.

Turns out there is. Enter Stream Deck. (Unpaid ad.) Add to that a dedicated Chrome plugin for Google Meet, et voilà:

So this thing, which connects via USB, has 15 buttons with little LC displays in them that can be programmed to trigger just about any activity by using its standard app. It’s apparently popular amongst streamers, but why should they have all the fun?

The aforementioned Meet plugin is a dedicated thing that directly talks to Chrome’s implementation of WebHID. That’s beautiful because no device driver is needed. The plugin is very well done: it reconfigures the buttons depending on the context Google Meet is in. On the Meet home page, it will show buttons to enter the next scheduled meeting, and to start a new unscheduled one. In the meeting, it shows the buttons you can see in the photo above. They also change when pushed: for example, the image for the mute button (bottom left) will turn red and show a strike-through microphone image while muted; and the button for raising your hand will get a blue background while the hand is up.

Since I took the picture, the features have changed: the Stream Deck now displays more buttons for interacting with the meetings, e.g., switching on/off the emoji reaction bar, and so forth.

Occasionally, Google decides on a whim to change the DOM ID of some of the buttons on the Meet page. That means the respective buttons on the Stream Deck stop working. It's an easy fix, though: simply inspect the page elements with the Chrome built-in tooling, change the plugin JavaScript source in the right place, and reload the plugin.

All in all, this is a productivity booster.

Tags: work, hacking, the-nerdy-bit

A3

Since I’ve been going on about juniors and onboarding recently, here’s one method that does good things for onboarding as well as team building at just about every level. It’s called the A3 methodology, originates from Toyota, and has been documented in detail in book form. I’ll leave looking up the details to my valued reader, and focus on putting the A3 method in context related to my earlier remarks.

Put very simply, the A3 method is about trusting people with finding solutions to actual problems from day one. It’s about giving them a sense of belonging and contribution as soon as possible. This can only work if the environment the new colleague finds is ready to support them in applying A3.

No one member of any team should be working as a one-person silo. Neither the new joiner, nor the seasoned senior. Freely providing and accepting support should be everybody’s natural behaviours. This ties right into what I wrote last week about a team’s knowledge sharing activities: onboarding is just another form of knowledge sharing. The A3 method provides a lightweight, structured, empowering way of kicking that off.

Tags: work

More on "Hire Juniors, Grow Seniors"

In the past, I've written about my hiring and team building philosophy, which I like to summarise as "hire juniors, grow seniors". In staffing discussions, I keep mentioning this, and frequently receive pushback from Engineering Leads and their Product counterparts that I'd like to summarise my responses to and thoughts about.

The most frequent arguments I’ve heard are that onboarding juniors takes longer, and that the technology new hires will be facing is so complicated that a senior is required.

On the first point, yes. Onboarding juniors takes longer. They are simply less experienced. The team that welcomes them has to bring them up to speed, and investing more time in that slows down the team. This is a fact that can’t be argued with. I want to challenge the perspective from which it’s used.

You can see onboarding time as necessary waste, and the extra time needed to onboard a junior as excess waste. “We could be so much faster.” The perspective here is that the team has one job, and that’s to deliver the next feature, or bug fix, you name it. People on the team can’t be bothered too much with onboarding, they want to get back to the job. The new team member - regardless of their seniority - is basically a unit that needs to fit in as fast as possible. The team is a gearbox, and all the parts need to move smoothly to perform their precise individual duties. When a part falls away, it gets replaced with the exact fitting spare part. Scale this to the organisation, and teams are exchangeable parts.

This perspective on onboarding, people, and eventually teams is rather sad. I prefer to see teams as places that provide growth opportunities. As mentioned in my previous post on the matter, a senior leaving means a growth opportunity for the next best person already on the team to step up and replace the one who left. This cascades down along the seniority levels to the (newly hired?) juniors. Onboarding, then, is just another way to provide a growth opportunity.

How does this growth happen? In part, by passing on knowledge and expertise. A senior leaves? As soon as that’s announced, handover to the successor begins. The senior’s successor will also give up some duties, and hands over to the next person. And so forth. Notably, this does not only have to happen when it’s clear that someone’s leaving. Sharing knowledge at all times ensures better overview of the systems a team is in charge of, more broadly shared expertise and, ultimately, more safety for the company by way of creating sustainable value. Circling back to onboarding, a team that constantly and habitually shares knowledge will treat onboarding as just another example of knowledge sharing.

The second point, our technology is too complicated for juniors to be able to grok it quickly, is actually related to the first in one way that I’ll get to after challenging the situation a bit. This will be a bit hard to swallow, but please bear with me.

Did I get that right? Our technology is so complicated that it takes a senior to grok it? Isn’t that embarrassing? Are we proud of overcomplicating things? That’s a problem, and we need to stop doing that. Don’t we have time to simplify things? That’s another one, please let’s talk about tech debt and making time for addressing it. Is stuff not documented clearly, and is it therefore too hard to grok it, and aren’t people willing to pass on that knowledge that’s in their heads? This one brings me back to the relation to point one above, as promised.

Complicated technology can be a result of people not talking enough. More active knowledge sharing will have the side effect of there being more discussions about solutions. Honest and healthy conflict about the best ideas will lead to better solutions, and that, here, means simpler ones. Or at least ones that more people understand. Which arcs right back to the question of onboarding speed.

Bottom line, onboarding time is time well and easily invested provided sharing knowledge and collaborating closely is a habit.

I will offer a third point in favour of hiring juniors that’s a bit more on the idealistic side. How well does the philosophy of hiring more senior people scale? Applying the categorical imperative, I can rephrase the question as What would happen if everyone preferred hiring seniors over juniors? At the team and company level, this doesn’t make much sense. As mentioned, this is about scaling - I’m thinking industry level.

People don’t start their careers senior. They start with a certain amount of skill and little experience, and learn as they go. It’s quite natural that there are more juniors than seniors in an industry. The seniority pyramid has that structure. Having the seniority pyramid upside down in an organisation (company, or team) is unnatural. If no one hired juniors, where would they learn?

It’s a matter of responsibility towards the greater industry to hire juniors and help them grow senior.

Tags: work

Communication: Quick Tips

Here are some gold nuggets for structured and audience-aware communication from my coaching trainer Maik. As with everything concerning communication habits, they’re easy to agree with but hard to adopt consistently. This is about habits, after all.

In brief:

1. Structure your communication with short labels or “headlines”, giving things an order.

2. Be aware of attention spans (they’re shorter than you think) and take them into account when structuring. Check in with the other.

3. Describe scenarios with structure to avoid going to story telling mode (e.g., the STAR model: situation, task, action, result).

It takes practice, but it’s worth it.

Tags: work

Sharing Pages in Logseq

Logseq is a real power tool for note taking and knowledge management. I had mentioned I’m using it a while ago already.

I keep my personal logs strictly separate from work related logs, for obvious reasons. However, there is one important part of the knowledge graph that is good to have both in the work and personal hemispheres: my collection of notes about articles and books I read. I’m going to describe now how I’m ensuring I keep this particular info synchronised across the work and personal knowledge graphs.

Thankfully, Logseq has a very simple storage model: Markdown files in directories. That makes it easy to use an independent synchronisation tool like git to synchronise and share parts of the storage. Logseq stores all individual Markdown files in the pages directory. It also has a notion of “name spaces”, where pages can be grouped by prefixes separated by the / character. For example, an article I file under Articles/Redis Explained will have the file name Articles%2FRedis Explained.md - it really is as simple as that.

I’ve made the root directory of my Logseq storage a git repository. I have a .gitignore file that looks like this:

.logseq
.gitignore.swp
.DS_Store

journals/**
assets/**
logseq/**
pages/**

!.gitignore
!pages/Articles*
!pages/Books*

As you can see, it excludes pretty much everything but then explicitly includes the things I want to share across machines: the .gitignore file itself, and any page that has an Articles or Books prefix. Occasionally, I will have to force-add a file in the assets directory, which is where images are stored. That’s manageable. The rest is git add, git commit, git push, and git pull, as usual.

With this setup, I can freely share notes about articles and books across my two Logseq graphs, and reference the articles and books from my personal and work notes easily.

Tags: the-nerdy-bit, hacking, work

User Stories, and Flight Levels

A while back, I had a chat at work with our Scrum Master Susmita Banik, and we came up with an interesting metaphor for the focus of work for PMs, POs, and engineering teams at Quandoo. The credit really goes to Susmita, I just like the metaphor so much that I can’t hold back. Please let us know what you think.

It started with us discussing quarterly product roadmap planning, and observing that PMs and POs are currently less than 1-2 months ahead of the engineering teams in terms of planning and backlog building. The desirable state is that while the engineering team is working on the top entries in the backlog, the POs are already preparing things to be there in one month, and the PMs are working on things even farther out. That allows for steady throughput.

One thing that apparently happens a lot is that discussions about user story slicing get lost in technical and implementation detail. That’s not what user stories should describe though; decisions about implementation details are in the hands of the engineering team. Occasional consulting with the PO notwithstanding.

It is indeed a frequent antipattern in meetings: they wildly flip between different “flight levels” or “altitudes” and go off track, frustrating participants and yielding no outcome. (This is surely part of people’s general frustration with meetings. I keep saying it’s not meetings that are the problem, but bad meetings.)

This is what the metaphor Susmita and I developed is all about: mapping types of work - and types of work typically done by certain roles - to something akin to flight levels. Here goes.

Think your favourite maps product. And think of charting and going on a journey.

The task of planning, usually driven and significantly carried out by PMs and POs, with some consultation from engineers, is the really high level view on the map. No physical details are visible (satellite image view is off). At this level, the point is to state “we’re going from A to B, and the route is roughly this, with maybe these milestones”.

One flight level down, the journey is charted, taking landmarks into account for orientation. Satellite image view is now on, and the zoom level is higher. This is typically done by POs, with more consultation from engineers. The focus is on going from one milestone to the next, and implementation details are still not the main topic, but may serve as orientation from time to time.

When the path is walked, and stories get implemented, the map is switched to street view. Details have full attention now, and rightfully so. Which corner to turn, which street to cross and where … these questions are now relevant.

What’s important is that zooming out to one or two levels higher is possible at all levels, as a reminder of what the big picture is like, and what purpose all of the nitty-gritty details ultimately serve. What’s also important is that everyone has a meaningful contribution that relies on their particular expertise. It’s never just a technical question, or just a high-level planning question, or just a story slicing granularity question. It’s the collaboration across these levels, in an appropriate and solution oriented way, that eventually brings everyone to the target.

As an example, take going from somewhere in Berlin-Friedrichshain to the Quandoo office by public transportation. That’s the high level view in planning. The stories are charted by breaking the route down into segments of the trip (likely ending with taking U2 from Alexanderplatz if it's not broken again, or M10 from Warschauer Straße). Implementation of each of the stories involves all kinds of detail decisions, like which entrance to take in an U-Bahn station, or where to cross a street. Even though different people may have contributed to these things at the different levels, in the end, the entire party gets to the office, thanks to the collaboration.

How does this work?

(Thank you once more for the discussion, Susmita!)

Tags: work

How I Onboard

When I started my current job at Quandoo in May 2022, some people inside and outside the company asked be how I go about onboarding. Responding to the question, I realised I was following the same approach that I had followed at the previous job, so there seemed to be a repeatable process. Here's how I do it.

The onboarding proceeds in four waves. Naturally, like waves do, they overlap and aren’t discrete steps I take one after the other.

Wave 1: People. The company consists of people. It’s people who do the work. They’re the most important part of the company. Trust-based relationships between people are what makes everything - work, and more “social” aspects of being at the same company - much easier and enjoyable.

I make an effort to very quickly start meeting literally everybody in my organisation, and that strictly includes people not reporting directly to me. I’m here for them as well, even if we don’t interact directly, so they’re as important for me to at least know as my direct reports. Also, I quickly meet and establish meeting cadences with key partners in other parts of the company.

Wave 2: Product. What do we actually offer? What do our customers care about? How do we identify what’s important to deliver, how do we prioritise and plan our work? This is not just about the product as such, but also a lot about the process we use internally.

To learn this, I engage with Product leadership to get an introduction to the product itself. Ideally, if possible, I also get test accounts, as well as access to the backend tools in use, so that I can connect the dots between all the things. I also talk to engineering leads about their teams' work and to POs, PMs, and Scrum Masters about ways of working, planning, and prioritisation.

While I do this, I consciously remind myself that during any stage of this, I’ve still barely scratched the surface. After all, this is onboarding, not experience - it’ll take me much more time to fully “get” everything. The good thing is that I know whom to talk to if I have a question (see above for Wave 1 and why it’s important).

Wave 3: Technology. How does everything work? What programming languages, frameworks, test and deployment strategies, infrastructure setups do we use? I’m not working as an engineer any more, although I remain one by heart, so I’ll be very interested in getting a decent understanding of all the things from high-level architecture to actual code. I’ll go as far as to try and make serious attempts at cloning repositories and running parts of our product on my laptop. While I’m not going to be spending much time coding, I still want to understand how it all fits together.

To that end, I try to find and read documentation, and where that doesn’t exist, talk to folks from engineering at all levels liberally. I’ll try to find whoever is the best person to share some knowledge, and ask them to share it. All that happens with great respect for people’s calendars and time management. I know interruptions are unhelpful, so I try to minimise them.

Wave 4: Backlog. What things do I need to drive personally? What projects should my org take up in the near future? What is the relative importance of all of these, in what order should we tackle them? The three waves above are all about me being a sponge. Eventually, I should start contributing and adding some value.

While I collect ideas and observations during the first three waves, the fourth is about turning the observations into action proposals, prioritising them, and then taking action. This, too, requires careful discussion with all the right people - I don’t like going in and breaking stuff just because I’m new and in a somewhat powerful position. In fact, being new means I’m certainly the person who knows least about everything.

Tags: work

Management Impact on Psychological Safety

The importance of psychological safety cannot be overstated. A somewhat recent example with some magnitude is the discovery that Toyota’s truck brand Hino has faked emissions data for decades. Reportedly, this could happen because management set unrealistic goals that no one dared to challenge. This, in turn, was because the culture did not encourage or reward speaking up, but rather was one of fear around raising issues.

This story is especially painful because Toyota, of all companies, is famous for introducing the “andon” cord for anyone to stop the manufacturing line, raise issues, and enable focusing on problems. This is a key part of the famous Toyota production system. Using such a tool is possible only in an environment that is psychologically safe.

Tags: work

Mobile IDE

iPads are nice, and the iPad Pro is a rather powerful laptop substitute - almost. While it’s really well possible to do office style work on an iPad, anything software engineering becomes hard, because IDEs involving compiling and running code on the device, as well as convenient things command line interfaces, aren’t supported on the platform. The manufacturer wants it so.

There are web IDEs. Unfortunately, they’re a bit frustrating to use when travelling (e.g., on a train in Germany, or on an airplane).

Raspberry Pi to the rescue. Of course. These machines are small, lightweight, don’t consume too much power, and are yet fairly capable as Linux computers. Real IDEs run on them. Compiling and running code on them isn’t a problem either.

The Tech Craft channel on YouTube has this neat overview of a mobile setup that combines the best of both worlds, using the Linux goodness of a Pi and the user interface of an iPad. It’s tempting.

Tags: work, the-nerdy-bit, hacking

Book Recommendations

A while back, I gave a colleague a book recommendation, which he liked a lot. He proceeded to ask me for more recommendations of “hidden gems” - thank you, I will gladly oblige!

The following are books that I’ve read and taken a lot away from. Insights, tools, process recommendations, you name it. The list is inevitably personal, and there’s no guarantee that you’ll find any of the books equally valuable. I’ll try to summarise the key takeaways as good as I can.

Bill McFarlan; Drop the Pink Elephant. This one is about communication. In particular, it’s about how to get across what you really want to say without coming across as a jerk, and about how to avoid misleading communication patterns that are so common most of us use them without thinking. It’s a light read, witty, with a lot of humour.

Daniel H. Pink; Drive. People are generally motivated by three aspects in a job: autonomy, mastery, and purpose. The book shares a lot of empirical study insights without going into heavy statistics. It’s helpful to understand how to go about translating company strategy “big picture” directions into language more easily appreciable by front-line teams.

W. Timothy Gallwey; The Inner Game of Work. While Pink’s book is more about understanding motivation in general to “get” how others tick, this one is more introspective. It has helped me understand how I can get better at a complex job without losing sight of the forest for the trees. In brief, it’s about focusing on “one variable” at a time, and experimenting with that.

These three have been very helpful, but the list wouldn’t be complete without mentioning the writings of Patrick Lencioni. I have read literally everything he has ever written. His books have considerably shaped how I think about all things management.

What I appreciate about Lencioni’s philosophy are two things. First, it’s very humane. He understands that businesses consist of people, whose needs and interests play a key role in succeeding. Second, Lencioni is simply incapable of proposing a complex model for any of the problem areas he discusses. His models are simple, and they make sense. Note that their simplicity does not mean they’re trivial to implement; they’re in fact hard to implement. After all, implementing them involves people.

Most of Lencioni’s books are written as “business fables”, i.e., novels of sorts, which are easy and quick reads because they’re not dry business books but stories. That’s not for everyone, but it certainly works for me. Each of the books contains the theoretical framework at hand as a summary in the final pages.

Lencioni’s overarching model comprising all of the above (and then some) is the concept of organisational health that he has summarised in The Advantage. This is his only book that’s written in a somewhat more dry business/leadership book style. It enables quick access to the big picture, being a really good summary of all the others. With one exception.

The latest addition to the list, The Six Types of Working Genius, is about a model of work and personal work preferences. It touches on all the topics covered before, but looks specifically at how we’re “wired” as personalities for the work we’re doing, and what kinds of work might be the best fit. (There is an assessment, and I’m a certified facilitator.)

I hope this is helpful - feedback is welcome!

Tags: work, books

Power, Always?

Do managers, when talking to their teams or direct reports, always speak from a position of power?

No. It is however an easy impression, and one important thing for those of us in managerial roles to keep an eye on.

Most of us honestly care about the people we’re responsible for. Sometimes this means giving some “tough love”, which is explicitly not the same as wielding power. It’s simply our job.

In these cases, it’s important to speak with radical candor (care personally, challenge directly) and avoid at all cost to slide down the slippery slope towards obnoxious aggression (challenging directly without caring personally). Falling into that trap is easy, and can easily cause a lot of damage.

It can help to bear in mind that we should always respect people, not titles. That makes for more natural conversations all around.

Tags: work

Bell Curve Wisdom

We’ve all come across bell curves. Hopefully not as a form to squeeze people into in employee performance evaluation frameworks, but that’s a different matter. Today, I’m all about the bell curve meme that’s used to (ironically) highlight how beginners and experts in a field often come to the same conclusions, while people in the middle prefer something of utter complexity.

Here’s a software engineering related collection. Many of the entries are thought-provoking. Where are you (yes, you) on these?

Thinking on, if beginners in their naïveté and experts in their experience-backed wisdom come to the same conclusions, what does that mean? Experience proves intuition right, right? Is there a short but rarely trodden path from intuition to pragmatism?

Bottom line: hire junior, grow senior, and listen to the juniors more.

Tags: work

Asking for Help

It often seems hard to ask for help, right? The article lists a broad range of possible reasons (quasi-quotes with slight paraphrases): they’re busy, they’ll be annoyed, I should know this, I’ll learn more by figuring it out myself, I’ve waited too long and it will look like long time no progress, they might not know and I’ll embarrass them, people might think I’m stupid, I should try longer and then ask if I’m still stuck.

Sound familiar? If so, read the whole thing; it offers a lot of advice as well.

I’d like to expand on the two final points a bit, from a cultural perspective.

People might think I’m stupid. So what? Not knowing something, I’m facing a choice: looking stupid, or staying stupid. I’ll err on the side of the former. If someone thinks I’m stupid just because I don’t know something and ask for help, that says a lot more about them than it does about me. I don’t need their approval, I need their knowledge.

I should try longer and then ask if I’m still stuck. This is a classic, it's hard to get this right. If the environment is unwelcoming and prides itself in street credibility by knowing everything, the time to ask for help is never right, because eye rolling will ensue no matter how much research you've done yourself. (See my previous remark.)

Surprise: you might be part of that culture. So, observe yourself next time someone asks you for help. What is your gut reaction? Annoyance? Eye rolling? Do you think the other person should have looked a bit more?

Tags: work

Meetings, Again

Meetings are a pet peeve of mine (you know that by now). My buddy Mitch Wyle (we know each other from eBay) summarised a Twitter thread on meetings in his blog and thought I might like it - well, yes and no. The suggestions amount to putting hard boundaries on the number of, and time spent in, meetings, and to enforce some rigour around scheduling them in the first place.

I'm skeptical about any approach that tries to address the meeting matter from an angle of time spent and then does things such as applying quotas and rules that all amount to putting an upper boundary on time spent in meetings. This often cumulates in simplistic takes such as that "meetings are bugs" (Shopify, 2023).

People shouldn't care so much about time spent in meetings, but about value derived in them. Consequently, optimisation attempts should target not time, but value.

I also strongly suggest that everyone, before taking any stance on meetings, should read Patrick Lencioni's "Death by Meeting".

Everybody hates a bad meeting. Knowing how to love good ones is surprisingly hard.

Tags: work

Meetings Aren't Bugs

At Shopify, the year began with a clear declaration on meetings: “meetings are bugs”. (Here’s a pointer.)

I say that’s nonsense, and retort with a hearty “oversimplifications are bugs”.

In all seriousness, corporate liking for catchy phrases bear the risk of painting a picture of reality that has nothing to do with what’s healthy and good. So, to put it all in context, here goes.

Granted, there are too many bad meetings. Those should be taken care of, either by getting them right, or by cancelling them. Those meetings have (not: are) bugs. This is a truism, no reason to make a big fuss about it.

The move at Shopify consists of several components. First, cancelling, for the time being, all meetings with more than two participants. It’s good that the value of 1:1s appears to be acknowledged. But imagine a team that uses a flurry of 1:1s, or some other contraption, instead of a daily standup to synchronise. The communication overhead would be maddening. Also, leadership meetings at the team level should typically involve engineering, product, and design leads - that makes three. Leave one out, risk the respective function to lose touch, with consequences for the product (and customer). And how exactly is the Shopify CEO going to run his staff meeting and ensure alignment in his leadership team? This move is so obviously nonsensical that I will boldly bet those three-plus person meetings will sneak back into the calendars in a short time frame. (Does anybody know anyone at Shopify whom I could ask?)

Second, no-meeting Wednesdays; and third, placing all meetings with more than 50 participants (shouldn’t those be cancelled, actually?) in a 6-hour window on a specific day. These moves make sense, because they help ensuring uninterrupted focus. That’s a thing everybody benefits from - engineers and managers alike.

Let’s be serious: some of the work we do at companies happens in groups of people. That’s called a meeting. If meetings get the right attention, they’re good tools to get things done. Eliding all nuance from the matter with a punch line like “meetings are bugs” is nothing but putting up a show. Whom are they trying to impress?

Tags: work

Guidance for Quick Decision Making

It's a healthy philosophy in engineering to be quick at decision making and then sticking to that decision, properly following quality guidelines and best practices. This sports a strong sense of agility, focus, and quality. A while back, a past manager of mine with whom I’m still talking frequently pointed me to an interesting thinking tool that can help with the precision of the “quick decision making” part. It’s about viewing decisions as one-way or two-way doors.

Simply put, a decision that’s a one-way door can’t be easily reverted, making and implementing it will have some sort of definitive cost to it. Conversely, a decision that’s a two-way door can be reverted without too much cost. How we go about making decisions then considerably depends on their nature.

For example, a new variant of a feature can be rolled out in a way that allows it to be switched off quickly in case anything bad happens - an undiscovered bug, or bad user response. Feature flags are what’s normally used to enable that. The decision to roll out the feature can be made very quickly, as long as the criteria for rolling it back or keeping it are clear, and a way to roll back is built right in.

As another example, a big initiative that moves the infrastructure from one cloud provider to another is one that can’t be easily reverted: contracts are signed, database architectures changed, and applications wired in different ways and sometimes even rewritten. Such a decision needs to be prepared carefully, and risks need to be analysed.

The article offers some ways of looking at the nature of decisions to carve out two-way door segments in decisions that look like big one-way doors. Perhaps one way of framing the difference is in terms of learning. What can I learn after making this decision, and how much actual pain will the learning involve? The greater the pain, the more one-way.

Tags: work

Badgers

Gadgets are fun, and even more so when they can make someone’s day.

Back at my previous job, one of my teams (named R2D2) had been working on a long and hairy project. Essentially, it was a complete rewrite of the core piece of Babbel’s language learning experience, the so-called “lesson player”. The project had started well before I joined (that was in August 2020), and was technologically involved. It took the team quite some time to deliver, and the "Universal Lesson Player" has gone live across web, iOS, and Android.

Before leaving, I really wanted to celebrate and acknowledge the success so far by giving a little token of appreciation to everyone who had contributed. It being me, that needed to be appropriately nerdy. I came across a device named Badger 2040: a Raspberry Pi Pico powered little thing with an e-ink display that’s programmed in MicroPython and can be configured as a name tag. Of course this was the right thing.

So I got some 35 of those, and went on a fun ride to prepare all of them until they looked like this (for the technically interested, there’s also a photo of the back):

It’s e-ink, so the display just stays like that. But if a user so desires, they can connect a battery pack and augment the code on the device to, for instance, react to pushing one of the buttons by displaying a QR code with contact information instead of an image. After all, it’s a programmable computer right there, and it even has a variant of the Raspberry Pi’s infamous GPIO capabilities. The possibilities are “endless” once one knows a little Python.

I was able to hand over most of the Badgers at a little release party, and needless to say, people loved it.

Tags: work, the-nerdy-bit

The Perfect Manager

John Cutler has a little piece on “the perfect manager”, wherein he notes that one key trait of such heroic figures is to shield their teams from bullshit from above. He goes on to question why that would be the norm, because it would imply that BS is the norm.

Obviously, part of my job is to represent the company to my teams, which may involve such shielding, and which more likely involves translating messages from “above” and from stakeholders. Notably, another part of my job is to represent my teams to ”above” and to stakeholders, which may involve translating as well.

Ideally, there is no BS that people need to be shielded from. Ideally, there’s clarity about priorities and their rationale. I would even go so far as to say that ideally, no translation is needed at all. In such a perfect world, people speak the same language and are on the same page about what needs to happen because clarity is established early and with the necessary amount of repetition.

In such a setting, I could just contribute to the work going on at my level, which involves such beautiful things as thinking about and implementing an organisational vision, and caring about people’s growth trajectories.

Patrick Lencioni calls the state in which this is possible because everyone operates with optimal clarity “organisational health”. I really believe it’s worth working towards.

Tags: work

Reporting

Reporting has a bit of a bad reputation; it’s sometimes associated with micro-management or command-and-control style. The existence of such excrescences notwithstanding, reporting is an inherently useful and good communication tool that helps create transparency amongst team members, in organisations, and “up the chain” alike. Guess what, there’s nothing bad about that.

I found this article very helpful for both engineers and managers, as it clarifies a fair share of the language and concepts around the reporting question.

Tags: work

Time For Something Different

Average retention of software engineers is actually quite low: “Around 50% of software engineers only stay at a company for two years before switching to somewhere new.” The money topic aside, I’ve spoken to several people who mused that after two or three years in the same workplace, “it’s just time for something different”. Frankly, I’ve never quite understood why that would be imperative.

It’s time for something different because ... ?

It’s time for something different so that ... ?

Asking for those extensions of the “time for something different” was often met with a shrug and an emphasis on the “just”: “it’s just time for something different”.

Back in May, I had a conversation with my coaching trainer Maik, who asked me about my start earlier that month at a new company, and the steepness of the learning curve. (Hint: it was very steep, and that wa expected, good, and fun.) Maik proposed that the learning curve when starting at a new company usually takes the shape of an S curve, plotting amassed knowledge over time, with a very steep gradient right at the beginning as new information comes flying from all directions. It makes sense intuitively: starting a new job, you learn a lot in a short time. Eventually, the curve flattens out at a high level: after a while in the same workplace, you’ve learned all the things needed to be able to do your job really well. Depending on the nature of the job and the complexity of the company, that can be one to three years.

Then what?

Is that, the point in time where someone realises they’re experiencing a flatter learning curve, the moment where they think “it’s just time for something different”?

It could be. But does that something have to be in an entirely different workplace, with all the anxiety and insecurity coming with a new job and environment? Can’t the different be found where you are?

In the rare case where you think you can’t learn anything more about the company, I’d argue that’s actually really good. You can spend less time learning about the company, and more - much more - thinking freely, learning seemingly unrelated things, connecting dots between those, and truly innovating. Having such a vast amount of knowledge at your disposal can lead to emerging new insights - which means you’ve learned something again. The curve flattens, but the weight of what’s learned “up there” can be much heavier than further down the slope.

There are careers like the one of Christian Klein, who joined SAP in 1999, aged 19, and has been working there ever since. He has worked there in different functions over the years, and is now CEO. Without ever having met him to ask him about this, I’m sure he always found something different.

Tags: work

Hire Juniors, Grow Seniors

Imagine that, on one team, Senior Developer X leaves. The gut reaction often is "We need a Senior to do this work." Now, hiring more senior people takes a longer time, and we must not forget that a Senior still needs to go through the same amount of onboarding as everybody else before they reach a productive level.

How about asking instead: “Who on the team is the next best person after X to do these things that X used to do?” There's your Senior-in-the-making now. Letting them fill the space X left behind gives them a perspective, and a space to grow into. That person is already onboarded and is just shifting perspective.

Of course, "Oh but that person is looking into those other things." OK then, who's the next best person to look into those instead? There's another growth opportunity, and more - a cascade of them.

Yes, that’s a lot of shuffling, and it disrupts the team’s setup and ways of working. (Change does have effects.) But rather than expecting everyone to just carry on and waiting for the hole to be filled with someone who has the right shape, how about morphing the team so that the hole goes away more instantly? There is a need for that work, after all.

More junior people are more quickly hired. Also, they bring fresh perspectives and new ways of thinking. Finally, a company should never be a place for senior people alone - it also has a bit of a societal duty to give more inexperienced people in the job market a place to start and grow.

"Hire juniors, grow seniors."

Tags: work

Finisher Metric

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

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

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

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

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.

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

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

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

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

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

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

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

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

"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

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

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

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

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

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

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

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

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

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

(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

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

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

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?

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

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

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

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

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

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

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

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

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?

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?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Tags: work

Deadlines

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