One of mine is an avid writer, and he sometimes treats me to sneak previews of his blog posts. This week, he showed me this one. One thing followed another, and here we are. Enjoy. Or, more likely, shake your head.
Stage directors, just like startup founders, tend to have oversized egos. That’s how they got to where they are in the first place. Those giant egos often lead to visions of similar size, and that is not always a good thing.
Letting an obsessive Elektra dig through a thick layer of sand on the stage floor because she cannot find the axe she kept to get her final revenge? Why not! Did someone carefully point out some flaws? Probably. Did it nevertheless make it into the final production? Absolutely!
(I’m looking at you, Stein Winge. This made no sense and was a terrible idea in terms of acoustics, too! I’m still mad about it.)
Working in startups is a lot like that. You compartmentalise the nonsense, focus on your job because you need the money, and try your best to avoid the worst outcomes.
Because you – obviously – have no power but enough skill and knowledge to draw your conclusions, you resort to silent judgement. At least you keep your dignity and self-respect intact even though you are forced to participate in ill-conceived activities.
Sometimes the only way is through. Disagree and commit!
And judge from under your wig and make-up.
Opera premieres are stressful, and so is release day. Now is not the time to joke about your baritone colleague’s chest toupé. He might not go out there for his big aria, ruin the well-oiled machine that is any opera performance, and it will be your fault.
It is also not the time to ask the engineers about edge cases or the designers about the correct pixel margins on those secondary buttons at the bottom of the screen. Someone will freak out and postpone the release, which will inevitably be your fault.
Don’t be that PM.
Sometimes things don’t go exactly as planned, no matter how much you’ve practised and how well-prepared you are. This is especially unfortunate when auditioning with high-stakes arias, e.g. those everyone knows by heart or that have technically challenging coloraturas. Botching those will not go unnoticed.
As a product manager, I sometimes have to present in high-stakes meetings, and sometimes things go wrong. Maybe I am caught on the wrong foot, or I realise that my case isn’t as watertight as I thought it was. What to do?
Cleavage to the rescue! Wear something with a deep V-cut, perform a well-directed movement at the right moment, and no one will notice. About to muddle your coloratura or backed yourself into a rhetorical corner? Quickly shake your shoulders, smile, and change the topic.
]]>After attending CSSconf EU, I started to think about what I could do with CSS variables to get the hang of it. Why not change the background color of a page once a visitor presses a key on their keyboard? Take a look at the demo to see how it turned out.
First, I had to assign each key on a keyboard its color. I didn’t want the hex codes to be generated at random, since that leads to a bunch of really ugly variations, so I went with named colors instead.
I wrote a little script to avoid manually creating a list of key value pairs for all possible keys, and ran that over the file containing my plain list of color names.
colors = Array.new
i = 1
2.times do
File.readlines('color-names').each do |line|
colors.push(line.chomp)
end
end
begin
color = "#{i}" + ': "' + colors[i] + '",'
i += 1
print color + "\n"
end while i < 256
The highest number representing a key on a keyboard is 255 but there are only 147 named colors, so I simply read the file twice, and stuff everything into an array. It’s no big deal if this list is not 100% precise.
I ran the script from the terminal, and piped the output into a new file. Then I simply copied the resulting list as a hash into my JS file.
const colors = {
1: "AntiqueWhite",
2: "Aqua",
... // all the colors...
255: "PaleGoldenRod"
};
I wanted to change the background color when pressing any key on the keyboard, so assigning a fixed color in CSS wouldn’t work. Enter the first CSS variable.
body {
--bgColor: DarkSlateBlue;
background-color: var(--bgColor);
}
I assign DarkSlateBlue
as a default so the page has a background color set already when loading. Then I use Javascript to update the value when a key is pressed.
I remembered the keyboard drum exercise from one of the first lessons of Wes Bos’ Javascript30 course, and I figured I could take a look at some of that code again.
const body = document.querySelector('body');
body.onkeydown = function (e) {
if ( !e.metaKey ) {
e.preventDefault();
}
body.style.setProperty('--bgColor', colors[e.keyCode]);
};
This sets the value of --bgColor
to whichever color corresponds to the key code inside the colors hash.
Mobile phones don’t show a keyboard when we open a webpage, so I decided to make the page change color on touch. And to make it interesting also for a single type of event, I assign a random color from my hash.
According to MDN, mobile Safari doesn’t play well with click events on the body of a site, so I worked around it by adding a main
section. This was then supposed to accept mouse clicks, and — fingers crossed — touch events.
<body>
<main onclick="void(0)">
</main>
</body>
Then I added a new function to handle the click event.
const main = document.querySelector('main');
main.onclick = function (e) {
const randomNumber = Math.floor(Math.random() * (255 - 1)) + 1;
body.style.setProperty('--bgColor', colors[randomNumber]);
};
First I create a random number between 255 and 1 which I then use to pick a color from the hash, and assign that to the CSS variable for background-color.
Quick’n dirty iPhone test. Worked. Nice.
While I played with the color change on the site, I kept thinking that it felt quite bland and boring. Let’s add some glitter!
I started with adding a single particle to the DOM to see if I could get it to work. Nothing fancy yet.
.particle {
background-color: GhostWhite;
border-radius: 50%;
height: 5px;
left: 10%;
position: absolute;
top: 10%;
width: 5px;
z-index: 99;
}
And in Javascript:
const addSparkles = function() {
let sparkle = document.createElement("div");
sparkle.classList.add("particle");
let main = document.querySelector('main');
main.appendChild(sparkle);
};
First, I create a div
with the class particle
, and then I add it to the DOM as a child of main
. Then I call the function from onkeydown
and onclick
.
Poof. The site changes color and displays a particle.
One particle is not going to cut it, I want more!
To make things interesting, I randomize properties such as size, placement, and shadow.
.particle {
background-color: GhostWhite;
border-radius: 50%;
box-shadow: 0 0 var(--blur) var(--spread) rgba(255, 255, 224, 0.5); /* GhostWhite with 50% opacity */
height: var(--size);
left: var(--left);
position: absolute;
top: var(--top);
width: var(--size);
z-index: 99;
}
I add variables to all properties I want to manipulate, and assign random values to them in Javascript.
const randomProperties = function (particle) {
const left = Math.floor(Math.random() * (99 - 1)) + 1;
particle.style.setProperty('--left', left + '%');
const top = Math.floor(Math.random() * (99 - 1)) + 1;
particle.style.setProperty('--top', top + '%');
const size = Math.floor(Math.random() * (6 - 2)) + 2;
particle.style.setProperty('--size', size + 'px');
particle.style.setProperty('--blur', (size * 4) + 'px');
particle.style.setProperty('--spread', (size) + 'px');
};
To create lots of particles, I add a for loop to the initial addSparkles
function. I want the amount of particles to be different each time though, so I assign a random number between 19 and 109 (99 looked good as a multiplier, hah) to the break condition.
const addSparkles = function() {
let maxCount = (Math.random() * 99) + 10;
for (let i = 0; i < maxCount; i++) {
let sparkle = document.createElement("div");
sparkle.classList.add("particle");
let main = document.querySelector('main');
main.appendChild(sparkle);
randomProperties(sparkle);
}
};
Inside the loop, I create a particle just like before, but now I call my randomProperties function to assign random values to CSS variables inside the particle
class.
But now all these sparkles pile up in the DOM whenever I pressed a key. This is not quite what I want.
So I have to remove them.
const removeSparkles = function() {
let sparkle = document.getElementsByClassName('particle');
for (let i = 0; i < sparkle.length; i++) {
sparkle[i].parentNode.removeChild(sparkle[i])
}
};
First, I create an array of all DOM elements with class particle
, then I loop over it, and remove each one.
I had to pause and think for a moment at this point because my initial reaction was to simply delete the array and be done with it. But the array only holds references to the DOM elements which need to be deleted from there one by one. This happens inside the for
loop.
Now I have particles, but still no glitter. Time for some animations.
.particle {
animation: var(--duration) linear var(--delay) var(--iteration) sparkle;
...
opacity: 0;
}
@keyframes sparkle {
0% { opacity: 0; }
25% { opacity: var (--opacity); }
75% { opacity: 0.9; }
100% { opacity: 0; }
}
I animate opacity on the particles for the sparkle effect. The values and keyframes steps I landed on are the result of taste-based tweaking, they felt right.
To kick the glittering up a notch, I use random values for the opacity at 25%, the animation duration, the delay, and for how often I iterate over the animation.
const randomProperties = function (particle) {
...
const opacity = Math.random() + 0.1;
particle.style.setProperty('--opacity', opacity);
const duration = Math.floor(Math.random() * (800 - 300)) + 300;
particle.style.setProperty('--duration', duration + 'ms');
const delay = Math.floor(Math.random() * (1000 - 200)) + 200;
particle.style.setProperty('--delay', delay + 'ms');
const iteration = Math.floor(Math.random() * (10 - 4)) + 4;
particle.style.setProperty('--iteration', iteration);
};
Again, the values are the result of trial and error until everything felt more or less right. No other reasons involved.
A fun side effect of combining these random values for the animation is that the glittering kind of fizzles out if you do not trigger a new round of changes on the page.
Just showing the page without mentioning anything about what to do was a tad cryptic. Initially, I had it spelled out which action anyone visiting should take (press a key, in fact) but that didn’t work well on mobile. So I changed the text for different breakpoints. But of course, that would fail on bigger touch screens like tablets, since I didn’t figure out how to detect those before any event is registered.
Enter emojis.
Everything is better with emojis. 💖
It stems from that one time we had just started dating and were hanging out in my kitchen after dinner. The conversation went like this.
“I'm going to put on the kettle. Do you want coffee or tea?”
“I can have what you want.”
“Okay, what would you like, though?”
“I don’t mind either way. What do you want?”
“I am asking you. It makes no difference.”
“No, really, I'll just take whatever you prefer.”
“You must know if you'd rather have a cup of coffee or tea!”
“Well… I mean… I'd probably rather have a cup of coffee if you have some…”
“Would I offer coffee if I had none? I'll get your coffee ready then.”
“But really… I don’t mind drinking tea if coffee is too much hassle…”
We probably went back and forth for a few more rounds until the water boiled, and I could pour one half of it into a teapot and the other half into a French press. It was the first of many conversations of this kind.
I was utterly confused by this dynamic until I learned about ask and guess cultures from Katherine Wu's presentation in 2014.
I am German; I come from an ask culture. I go through life assuming that I can ask for what I need and that people will either agree or tell me “no” in polite but no uncertain terms. In Germany, there is little ambiguity here. That's why I expect asking someone if they want tea or coffee to be a straightforward conversation.
My partner is Norwegian; he is very much from a guess culture. When he hears the question, a whole different scene plays out in his head. For one, he cannot know for sure that I have coffee in the house even though I offer it. Then, if he replies that he wants coffee, I might make some even though I had personally prefered tea. He would feel bad for effectively forcing his preference on me, so in an attempt to resolve this awkward situation, he tries to tease the necessary information out of me. Then he can avoid asking for something I do not also want in the first place.
Life can be pretty complicated sometimes.
I was reminded of this today at work when a coworker told me about how hard it can be for them to make their opinions heard and to have their needs acknowledged by their teammates. They are the only “guesser” among “askers”.
As the current trend for remote work in our industry is unlikely to slow down anytime soon, our teams are becoming more and more culturally diverse. It makes our work environment a lot more exciting and challenging at the same time.
When we collaborate with people with communication styles different from our own, we should be aware of these differences. We “askers” need to be more mindful of what we might be missing when the “guessers” around us are trying to tell us something, and we need to pay attention to the “guessers” inclination to comply with every request we may throw at them.
Because there is a risk of implicit power asymmetries when we as “askers” work with “guessers”, I believe it’s up to us from asking cultures to make the first step and give space to those from guessing cultures. We will all be happier for it.
After almost 15 years in Norway, I have finally learned to pad everything I ask for with disclaimers that make it very clear that it is okay to say no, but I am still struggling with the subtle hints and non-answers – often resounding nos – that go straight over my head.
The coffee or tea situation is so common in Norway that the national broadcaster even made a skit about it.
]]>This talk has been years in the making. You could say it’s the sequel to my “Developers, start designing!” talk. When I was looking around for a new job last autumn, I had the “pleasure” to read enough job ads to become irritated.
Product Owner is a role on a Scrum team. The product owner is responsible for maintaining and sustaining the content and priority of the product backlog. The most important aspect of executing this role well is creating backlog visibility inside the scrum team and across the organisation. Scrum is not prescriptive in who should take on this role; Ken Schwaber describes it as highly dependent on the organisation and the product. It can be a domain expert, a project manager, a department head or anyone else who is ultimately responsible for the value created by the team. Think of it as the organisational sponsor.
You could argue that I’m splitting hairs here and that it’s semantics. And that might be true if the title Product Owner didn’t show up in job ads and descriptions with a distinct set of tasks and responsibilities based mainly on Scrum rituals and artefacts.
Scrum (and other agile frameworks) is all about the smooth, efficient, and incremental delivery of software solutions. They allow us to create value for our customers, users, and businesses. They help us continuously assess if our solution is useful and avoid wasting a lot of money.
The world has changed a lot in the 20 years since the inception of Scrum, and so have our creation and delivery practices. We have incorporated UX design to make sure our solutions are not only useful but also useable. Our digital design practices have evolved to support incremental progress; we have design systems and CI/CD. Although not all of us in this room might currently employ these techniques in practice, we have the process down. We’re optimising.
Every time we think about optimising our delivery, we think about how we can best ship products. We want to create valuable and useable solutions, and we want to do it with as little waste as possible. We are concerned with what we deliver, with what our output is. We want to make sure our work flows as nicely as possible through all necessary steps to our users where it creates value for them and our business.
Agile software delivery is about discovering the right solution. Even if we practice it as intended—which we often don’t, but that is a different talk—teams refine and deepen their understanding of requirements and needs within the boundaries of the chosen solution. We always chase a local maximum. This is by design because it enables teams to be focused and efficient in executing towards goals. It’s just not all there is to developing software products.
Let’s take a look at a specific example. A team is asked to develop a chatbot for an online retailer. Usually, this type of request comes with a list of expected functionality. Who decided that what was needed was a chatbot? Is a chatbot the only way or even the best one? What is the desired outcome of delivering it? In this scenario, it’s left to the team to find out how to create a chatbot that meets expectations but not if the team should deliver a chatbot in the first place.
Scrum doesn’t help us figure out which problem we should solve. It assumes the problem is identified and deliberately black boxes the process. It’s simply none of its concern.
Suppose all we consider is our agile delivery framework of choice. We will likely end up in situations where product owners are reduced to being the interface between the backlog and the business, gathering requirements on one side and reporting progress on the other. It’s not a good place to be in, and needless to say, it’s not what the role was intended to be either.
We need to extend the box we’re operating in to include discovering the right problem before we move on to finding the right solution. There are plenty of ways how to do that. There is the lean startup movement, design thinking methods, jobs-to-be-done. Plenty of books have been written about this topic. We have all this knowledge available to us. I don’t want to go further into the details here; that is another talk.
My point here is different: we need to stop treating problem discovery as someone else’s job simply because Agile isn’t talking about it. We can and should do both in the same team. Let us own the desired business outcome as a team, and trust us to figure out the best way to get there.
Too many product companies still consider Scrum or any other agile development framework as all there is to product development. Their mental models are still defined by the deliberately black-boxed model that these frameworks present. As long as there is no change, teams will be stuck in an output focused mindset. It is hard to break out of this habit and go after the real opportunities in this context. When solutions are handed to us to deliver, all we can excel at is delivery. That’s why we’re so good at it!
Sadly, we leave a lot of value on the table when we operate like this. Our teams do not take full ownership of the business outcome, we don’t know what we’re aiming for, and ultimately, it’s close to impossible to hold us accountable for any high-value goal. Job ads that call for product owners instead of product managers are only one symptom of this limiting approach and only so happen to irritate me enough to send proposals to conferences about it.
Special thanks to Sofia and Georg for feedback and proof reading.
]]>Utter exhaustion from overwork had become my leitmotiv in 2020 and 2021.
I tried to do the job of three people, and I tried to do them well. Too many parts of the business depended on me, or at least that's what I thought. People kept throwing me curveballs. The pay wasn't great, and I was constantly broke. I wasn't only overworked, I was overwhelmed.
I've known it for a while – it played a large part in me changing jobs – but the end of year reflection among the PMs put it into sharp focus: this is neither a healthy nor a sustainable way of living.
Since the beginning of January, I have experimented with various habits to teach myself a sustainable working style, and most of all, to regain my energy for anything else.
I had effectively lost track of how many hours I worked every week. It never felt like I had gotten enough done during the day.
Now I am tracking everything as if I was billing by the hour. This has helped me a great deal to learn what a normal workweek looks like. The tracker shows me when I have clocked enough hours and it's time to log off for the day, even if some tasks are left unfinished.
I am really bad at leaving my desk and taking a break. A real one, without reading Slack on my phone or answering emails. I am tracking those as well, and I try to end up at around 1,5 hours per day.
Those regular breaks have added a level of calm to my days that I hadn’t expected. This has a lot to do with how people at BRYTER use Slack: it feels closer to email than instant messaging and lacks the constant urgency I have experienced elsewhere.
At some point, late work simply got out of hand, which inevitably led to me falling asleep way too late, getting too little and too poor quality sleep, and waking up groggy the next day. Now I try to stick to an 8-16 schedule as much as I can. If I do have to work late, I make sure to take a longer break during the day, rather than piling hours on top.
Unfortunately, this habit is still very much a mixed success. I still fall into the trap of “I’ll just quickly finish this one thing…”, but less often. It’s progress.
It's just not good for me, and it's not necessary at BRYTER either. I sometimes check Slack after hours in case I am waiting for something, but I do that from my laptop. And nothing that ends up in my email inbox is urgent, ever.
Not having my phone connected to work communication makes it very easy for me to “ignore” everything that happens after hours. If anything is on fire, people will always be able to call me.
It's a bit too early to conclude, but the situation is improving in almost all areas. I get more and better sleep. I spend more time with my family and less time scrolling on my phone because I am too tired to do anything else.
And last but not least, the fact that I managed to write this article at all is proof of great progress.
]]>In this talk, I give a brief introduction into the product management process, introduce a model to help visualise the pieces, and leave attendees with pointers for their own deeper research.
https://twitter.com/troubalex/status/1423179515522600967?s=20
Eventually, Einar chimed in, and the topic of rants came up. I have a lot of those in me.
But for some reason, I never feel comfortable writing them down, let alone publish them. I generously share my rants with people face-to-face though (I guess I’m sorry, everyone).
So what gives?
For one, having a strong opinion on something doesn’t necessarily mean you’re right. Sometimes you’re just a bit naïve, sometimes you’re outright ignorant. The former can be cute, the latter quite offensive. Neither makes you look particularly smart.
I don’t enjoy looking dumb in public, and I have enough self-insight to see that I have a decent chance at actually being misguided.
So there is that.
Add the baggage of my educational background. I didn’t follow a “traditional” path, I have no formal education in my field. I am easily dismissed, even more so when I get things slightly wrong.
At the same time, I don’t feel like publishing even the strong opinions that I am pretty confident about because they ruffle feathers and I step on toes.
In the end, it boils down to my own insecurities and an aversion to heated online debates. And of course enough of a delusion that anyone would actually read anything I publish.
Am I holding myself back without much reason? Quite likely.
Maybe we should all reflect on where our insecurities lie and where we’re censoring ourselves?
]]>The entire podcast is dedicated to career changers like me, and should totally give it a listen. It's good.
]]>I am not into books on productivity hacks, because they never solve the problem of mediocre productivity but try to give advice on how to cram even more into any given day. I have extensive experience with that approach, and it’s not for me.
In this case, I got interested because Eva had started to implement a few tactics outlined in the book, and they felt like they might be useful for my woes.
So here it goes.
If I wanted to boil down the entire book to one main idea, it is this one: to lead a meaningful life, we need to focus our efforts on activities that create value, and reduce everything else to an absolute minimum. Time is our most valuable resource, and we should be deliberate about how we spend it.
Sidebar: the idea of value here is not limited to economic or monetary value. It is up to each of us to define what we value.
Me being me, I imagined “deep” work to be something magical, a state in which groundbreaking thinking happens. As I see it now, it is about undistracted, focused work on challenging tasks, like preparing a presentation for a conference or reading a business book and taking notes that lead to original thoughts. In other words, tasks of value that I do and which would benefit from less of a scattered brain.
But it’s also work that directly contributes to one of my personal or professional goals.
Shallow work on the other hand is all the low-effort, low-value activities that fill our days, like playing email ping-pong to agree on a good time and place for a coffee meeting (my personal pet hate!) or doom-scrolling Twitter.
The challenge is that this shallow work is a) easy to do, and humans are lazy, and b) the busyness makes us feel productive. We have to make an effort to avoid spending all our time on this type of tasks.
Reflecting on this particular point made me realise why I have been feeling both empty and stressed at the same time over the last 6 months: I spent way too much time in the shallows than is good for me, and way too much of my time was spent on reactive work.
(I’ve made a number of changes since last autumn, but that’s a topic for another day.)
Newport argues that there is no other way to be deliberate about how we use our time than planning and then sticking to the plan. I’ve been a fan of task blocking since forever but as a tactic it’s easier to subscribe to in theory than it is to follow through with it in practice.
What I got wrong though was that I tried to stick to the plan like it was the law, and then ended up stressed out because, unsurprisingly, I was overly optimistic about how much work I could squeeze into any given day. And in addition, life kept getting in the way.
The point however is that the plan is not at all meant to be a dogma for how the day is supposed to go. It is a tactic to turn off the auto-pilot, and “treat your time with respect”.
Also, “overflow conditional blocks”. Very smart.
If you’re not sure how long a given activity might take, block off the expected time, then follow this with an additional block that has a split purpose.
I kept wondering though… all this deep work sounds like a solitary exercise. This does make sense for someone writing a novel or devising a grand theory. For a lesser mind like mine however, random ideas like the ones I am exposed to during a conference’s hallway track, are valuable.
Here is the thing: yes, I am exposed to new ideas and thoughts during a conference or through someone tweeting something unexpected into my time line. To make them into something valuable, I need to mull them over by myself.
A major point, and one that I have been epically bad at before: resting is crucial if I want to do any deep work. Relatedly, boredom is essential for my ability to focus.
That it’s important to get enough rest if you want to do your best work makes sense. It’s hard to do anything challenging if you’re dead tired. Getting enough rest is also central to restoring our attention, and subsequently our ability to focus. And yes, talking walks in nature works wonders.
I had underestimated though how severely constant task switching ruins our ability to concentrate. It’s undoubtedly exhausting, but it had never occurred to me that it could be the reason I found it hard to focus.
It’s in essence why Newport calls to quit social media: it’s context switching taken to an extreme. Instead, it’s good to be bored because it increases our tolerance for “an absence of novelty”.
This is my favourite take-away, and it’s also the hardest.
It all comes together: the use of time blocks to be deliberate with our time, constraints imposed by work-free evenings to force a focus on the most valuable work, a better, less reactive approach to email. All in support of defending our time, our most valuable resource.
It is hard to put these strategies in practice. They require a clear idea of what is a valuable activity, the ability to answer requests with a firm no, and the discipline to stick to them even when we fail.
“Deep Work” was a great read, and it gave me plenty to think about. I have a better understanding of the behaviours that lead to me being stuck in a bad place, and I have strategies to avoid getting there in the first place.
I’ve started experimenting with tactics from the book, and while it’s too early to conclude anything, it looks promising.
☞ Newport, Cal. Deep Work: Rules for Focused Success in a Distracted World. 2016
]]>Concept Stories vs. Origin Stories
“Where concept stories describe why someone might want to use a product, origin stories illustrate how they find it and then why and how they use it for the very first time.”
“The key to developing successful origin stories is that you call your main character to action and determine how to measure that action once they acquire their goal and in every step that leads to the end.”
Start with three simple questions:
Links are obviously broken all over the place, and images have gone missing. If I ever get really bored I might fix those 10 year old posts.
]]>One of the points I covered was basically how I adopted techniques I learned during my time at KDE. Later, that got me thinking about how those experiences prepared me for the work I am doing now, more than 10 years later.
It's maybe not surprising that the needs of individual contributors don't differ much: we all want to belong, feel safe, and be seen, and we want recognition for the work we do. Pretty much all I did when working with KDE and Qt communities was centred around those principles.
The struggle with written communication is pretty much the same too. Language barriers, different styles, and all kinds of missteps in tone all need constant attention and effort. I spend time and energy on moderating mailing lists and forums, and later supporting the volunteer moderators I had recruited from the community.
It's funny how things change for the better, once someone makes a conscious effort in these areas.
When it comes to building and leading the team at VIBBIO, I focus my efforts in pretty much the same areas. The only difference is my formal position as manager.
]]>I usually tell folks that it really depends on how secure they feel with what they know and what they don't know. Chances are that you have to jump into something completely unexpected that will make you feel uncomfortable. It's okay to feel like that but you should be honest with yourself: can you sit with the discomfort and do the best you can?
]]>Let's try something different. I need to get my perfectionism under control when it comes to writing, so I decided to follow Elisabeth's example, and try a low-key way of writing down things I learn or stumble upon. Kind of like a log.
I constantly learn new things about building product, growing a team, and creating a company from nothing at VIBBIO, I might as well jot it down.
]]>If you don’t read this entire post, or if you take nothing else away from it, then just remember these points:
I think this is a winning strategy for all those who are involved in design or development blogging, as well as tutorial writing. -- Publish What You Learn by Louis Lazaris on Smashing Magazine.
My first reaction was "duh!". But then I thought again and asked myself if I really do write about the things I learn. Obviously, I dont. Since it's so obvious to me, the question is "why not?" It seems to boil down to a couple of reasons: First, I'm lazy. Blogging is a lot of work and I don't always have the energy, or patience, to sit down after work and write. I also have other interests, so the lack of time doesn't really help either. Then, I tend to over-think it. Writing a blog appears to be a major undertaking: I hardly ever manage to think of a blog as a relatively limited task, even if I don't plan to write a comprehensive project report. Which is a bit silly because I am happily using Twitter and Posterous to capture all my not so very brilliant thoughts and comments. I could as well use it for other things. I also constantly battle my inner critic* that keeps telling me that everything has been said about a topic already, and most likely by more qualified or experienced people than me. Chances are, they are better writers, too. Of course, I know it's stupid, it still sets the bar for myself too high to even get started. Finally, and that is the most interesting part, I don't necessarily see the things I have learned. How could I publish them? I am constantly learning. If I should make a list of the top 5 things I have learnt during the last week, for example, I would be at a loss. Fine, I learnt some useful tricks in spreadsheets but that is probably not very exciting. Speaking of it, the actual insight I took away from this week was probably that they cannot be avoided for certain tasks, no matter how hard you try. In this particular case, I was -- and still am -- working on a content inventory of qt.nokia.com, and after trying to squeeze it all into a mind map I carved in, and put all the pages into a spreadsheet. The bigger thing I learnt however, was how to compile a content inventory that actually makes sense. To blog about this would surely be a major undertaking, and I am certain someone has written extensively about it already... *) Wonderful article by Denise Jacobs on the topic: Banishing Your Inner Critic on A List Apart.
]]>One of my all-time favourite children's TV show went into it's 25th year at the time. I still watched it on a regular basis and so I had an idea. Why not send a special greeting card? One that would be fun to make and a bit different?
I had been playing with HTML and spent a decent amount of time on mailing-lists and in usenet groups. So I sent out a call to action to some German groups and asked for small text contributions to the greeting card . And I asked people to spread the idea. I don't remember how many people replied but in the end I had a nice collection. I charmed a friend to upload my orange page to the tiny webspace he had available at university.
Looking back it appears to be a small thing but it taught me something important: if you have an idea, run with it. If others like it, run the whole way. The tools have changed and my approach to community has matured but at the heart of it, this lesson still stands. (Thank you, Birte, for reminding me today!)
]]>View more presentations from Alexandra Leisse.
If you are interested in the rest of the talks, head over to the KDE Promo channel on YouTube and take a look. Slides are available from here.
]]>This is obviously the first step. Usually, the call for projects closes several weeks before the event takes place. As soon as it is open and you have decided that you'd like to be there send an email to the kde-promo list. Ask if anybody has already registered a booth and/or would be interested to organize one together with yourself. Go to kde.org and copy and paste the usual about blurb on the front page for the registration or look for one of the translated versions. It keeps things consistent and saves you a lot of thinking.
Don't be afraid if noone speaks up when you ask for physical presence. The usual reaction is something along the lines of "what do I know today about what is going to happen in 6 weeks?". In most cases you will find someone coming along and do booth duty. Don't be afraid to get on people's nerves. Set up a wiki page on community.kde.org (which is currently a building ground, but fear not!) to collect all information regarding the event and the staff. This will help you to organize accomodation and keep an overview. Keep nagging people to put themselves onto a list there and set a deadline**!**
An empty booth does not really make sense, you will need something to show. Good news is that the KDE e.V. has an awsome booth box that can be sent around for events. Ask for it on the kde-promo list and Claudia will let you know if it is possible. She might also just send you t-shirts and stickers and other things via mail if shipping the whole box is not feasible. For any place outside Europe, we are still looking into the options we have for booths. Ask on the list if you are planning to organize one and need anything. If you have to manage without the booth box you will need to think about hardware, too. Usually one or two laptops with a recent KDE installation including some demo data like images, music, movies, office files etc. The upcoming marketing sprint in Stuttgart is supposed to come up with a clever solution to the problem of demo data, watch out for updates from that front.
You may have to rely on non-locals for your booth who need funding for their travels. Find a room for them and ask them to add their travel costs to the wiki. Again, set a deadline! Some weeks prior to the event you should have all the costs collected on the wiki and send an email to kde-ev-board [at] kde.org and ask for funding. You should get a positive reply in a timely fashion and then you can push people to book their travel. Everybody staffing the booth should put their arrival and departure times into the wiki and provide the mobile phone number. That way you will have all the information you need at hand and can reach everybody if anything goes wrong. If you are collecting mobile numbers privately I recommend making a list and sending that to everybody helping out at the event.
Someone will have to take care of setting up things before the event starts and packing up after the end. That does not necessarily have to be you. Make sure that this is clarified beforehand so you don't get stressed when the event starts. Then let everybody know where they have to be and at what time. If the event is big and you have enough staff it may be a good idea to make a schedule for booth duty.
As soon as the event has started the worst things are over. Now it is time to enjoy what you are doing. Show those great technologies to interested people, answer user questions and look for the "Aha!" expression on their faces, talk to the folks at the other booths and all in all have a good time!
Sometimes you receive questions you didn't know how to answer or a concrete request. Remember to follow up on them when you're back and get the right people in touch with each other. If you have the time write a short report on the event with all the things that both went well and that didn't to the kde-promo list. We're always interested in things like that. Oh, and what about a blog? Or a story for the dot?
]]>If you choose a product on the MOO website you are given the option to import your photos from flickr, bebo, facebook or etsy. Since many people upload polished images to those sites it makes total sense to use those 3rd party APIs and make it as easy as possible to use those photos. But that is only the product site of things. MOO is present on all of the services they integrate into their website. A quick flickr search gave me 185.545 image results and 2 groups dedicated to MOO products. One of them started by MOO fans dedicated to trading MOO cards.
MOO's customers apparently already use a service like flickr to store their photos and have them printed onto the products they order. As they are custom made and unique in style they come with that special excitement about individualism that then motivates us to show them around. What would be more natural than uploading photos of them to flickr and blog about it? By smartly integrating a service like flickr into the product MOO builds a community as their main differentiator and gains an enourmous amount of visibility. It is no surprise that bloggers picked up on the small British business quickly after they launched their website.
There is a zillion online printing services out there, you can order business cards everywhere. Just like you can download software everywhere on the net. The difference is the community around it. People form groups around things they like, be it cards or software, and team up to help each other or simply exchange thoughts and ideas. Members of these groups will then tell their friends and the groups will grow by themselves making the product more visible and in the long-term more successful.
]]>When the Cluetrain Manifesto hit the public 10 years ago, it proclaimed a radical change in marketing with their 95 theses. The times of corporate controlled messages being broadcasted to an attentive audience are over, people want to be involved into how a product is developped and marketed, they want to see the human face behind the corporate walls, they want to be able to get in touch with those working on the product unfiltered by boring customer support. And they want the ability to spread the word about products they like. Sounds familiar, doesn't it? The big corporations have been adopting to this new reality for a while now and it seems that they finally understand that building a relation with their customers is what they need instead of huge and expensive ad campaigns. To build those they have to be part of their audiences' lives.
What sounds revolutionary in a world of corporate PR is business as usual for KDE:
We have been building relations to users for ages, it is our biggest advantage. We have established a big and healthy community by being part of it for years. We understand what users want because we use our software and listen to what they ask for. And we are honest.
With the adoption of social media techniques in business, those basic rules of community building and user interaction make it into mainstream. Seen from our cozy corner of niche this might indeed be a scary process: with new tools like microblogging new people join the conversation and our old patterns of communication do not necessarily work any longer. But we do have a solid basis of community work and years of experience to build upon. Some might be worried about losing control over what is said to whom combined with an unmanageable amount of people who might read and spread the information. But is this really a new situation? I believe it is not. It has never been possible to control what users tell their friends, their bosses or during talks at events. It was just less obvious. We have to believe that everyone acts to their best knowledge, all we can do is prepare those who talk about KDE in the best possible way. Don't be scared, embrace the chaos. What do you think?
]]>... the driver recognizes you when you get onto the bus to your local airport. ... you don't even look up the number of the check-in counter anymore. ... you have all your make-up in a little bag you don't even unpack anymore. ... you have various cosmetic products that are labeled in foreign languages. ... you find yourself postponing the visit to the duty free shop because you will visit a bigger or better one soon. ... you know how to say "To the airport, please" in at least one more language than you actually speak. ... you regularly schedule tasks for the time on a plane. ... you always carry your passport in your bag. ... you seriously consider buying a share of your favourite airline that doesn't have a frequent traveler programme.
]]>Image via Wikipedia
1.5 years ago, Franz was in the same position as I am now: he needed a helping hand. And unfortunately it's the same event again. There is an OpenExpo in Winterthur coming up on 23rd and 24th September and so far noone has stepped up to organize it. These expos are nice events (incl. catering) and stunningly well organized by /ch/open - there is really not much to do. So it's the perfect opportunity for beginners. If you don't have any plans for those days and would like to dip your feet into booth organization, drop us a line at kde-promo at kde dot org. I can send you last year's material for registering the booth and am happy to help out if you run into questions. Deadline for registering the KDE booth is 19th June. Update, 19th June: Myriam was so kind to register the booth in time. She will need some help though. You can still raise your hand and get involved. :)
]]>First figure out which weekend will fit most possible attendees. Propose no more than three different ones in the beginning or you will never come to an agreement. The last one should be about eight weeks away for a normal amount of organization, like finding accomodation and booking trips. To make your life easier while coming to an agreement on the date, use a tool like Doodle or set up a simple table on a wiki. And set a deadline.
As soon as you have the date, book the location. Be it a room in a school or an office, the longer you wait the bigger is the chance that someone else has sneaked in. And then you will have to start anew or spend hours on finding an alternative.
Set up a list on a wiki and ask everybody to enter the following details:
When you have all the information you need, find a hotel, an apartment or whatever fits your group and ask for room rates and availability. Depending on the size of the group, the latter will be the biggest work. I have managed to find something every single time so far, though. It makes things a lot easier if you are local or at least speak the right language. If you don't ask for help. Now it's time to contact the e.V. board and ask for sponsorship. Calculate the costs you are expecting and explain how you are going to spend the money (e.g. flights, accomodation). In most cases, a proper guesstimate on the travel costs will be enough. You should receive a positive answer in a timely fashion.
Now that you have approval from the board, it's time to start the actual booking. Push everybody to book their respective travel. Push hard! Set another deadline and hunt everybody who hasn't booked. Extend the existing wiki and ask everybody to update it with their travel information such as arrival and departure dates. Then finalize the rooms. Be prepared that a hotel will ask you for a credit card as security. If that is beyond your possibilities, ask for help in your group or contact the board again and ask what options they have for fixing this.
After you finished all the booking and know all the little details, send out an email to everybody involved telling them all they need to know: name and address of the hotel, name and address of the location you are going to meet and if possible also travel details. I strongly suggest circulating your mobile number, there will be attendees who get lost or have forgotten where they should change the bus.
Now the biggest things should be sorted out. But. There will be smaller things coming up. Be prepared to play baby sitter for some more days until the whole event is over and that you will have to answer a lot of questions during the preparation phase and after the event. Document as much as you can on the wiki (or elsewhere) for later referral and in case you drop off the map. Going through those steps, you will notice that the amount of hunting people and getting on their nerves to find the information you need will increase dramatically as date of the sprint comes closer. And don't expect anybody to say thanks. But be happy if somebody does...
]]>During the whole weekend I sensed positive vibes coming from the core developers who were relieved to have finally released. For me, this is the biggest improvement compared to the sprint we had last November. The announcement of Jos van den Oever as first full time developer working on KOffice (who brought great drops!) and the rather high amount of completely new faces surely added to the good mood.
Thanks go to Cyrille for his excellent release management that lead to 2.0 and agenda planning for the sprint, to Thomas for the lovley stickers and postcards, to KDAB who were kind enough to host us at their office and provide us with enough coffee and to the KDE e.V. for sponsoring the whole event. And of course, to everybody who came to Berlin to contribute, discuss and learn.
]]>The smartest thing about Firefox is its extendability. There is a ton of more or less useful add-ons available on Mozilla's Add-on site that solve even those issues you have hardly thought about before finding the extension. I collected a list of extensions I use more or less every day for my colleagues who will jump to my side on the internet and I thought it might be of interest to more people. It's a huge list that covers a lot areas from the usual Google enhancements to more juicy things like Geasemonkey scripts and I will split it up into several blog postings over the next weeks.
]]>"The 4.5.0 release contains a myriad of new features, bug fixes and performance improvements. Many of these are a result of the feedback we have received from you, the community of Qt users. Your continued support and feedback is a big part of what makes Qt such a great product."
It's the first time that a complete Qt SDK is out in the wild: it provides developers all they need for cross-platform Qt development in one single binary package and includes the Qt libraries, Qt Creator and the Qt tools. New Qt developers should be finally up and running in no time. Even I managed to install it on my machine and compile a small application. And take a look at this lovely video on YouTube! [Update] Eike blogged about the work on Qt Creator and the Qt SDK packages (and some other things). Honoured readers - this way, please
]]>CampKDE was a cozy but great meeting and I really enjoyed spending time with people I already knew rather well and those I hadn't met before. Although distractions were many, I got to all the topics I had on my list and learnt a lot from Mauricio and - I must admit - Wade. Quite some new ideas take shape in my head and I really hope to make at least a part of those reality. For example: what do members of the Spanish speaking communities think about a Spanish blog aggregation around KDE? What about Portuguese? Is there already a place for this on the web? Please, comment with thoughts and hints, I am not really at home in both languages...
And speaking of the net: there is a flickr group collecting photos from campKDE. So if you happen to have your pics uploaded there, shoot me a message and I will add you to the group so you can share them there.
]]>Less confidential but not less interesting is the feedback I got on my web concept. Actually it was bought by everybody, only minor issues had to be addressed. We still need to make a final decision on the system we want to use for the landing page - which includes quite some googleing for me - but chances are high that I will come up with something easy to use, easy to maintain and pretty. Thanks to Jarosław for pointing me into a new direction. I hope this might be useful as test case for other projects, especially the lifestream system to show the whole activity around one project that happens anywhere on the net.
It was very interesting for me to meet all those people I only knew from IRC, if at all, and see how they think, work and talk. And I finally understood the usefulness of chatting on IRC while being in the same room: one gets the attention of those that keep staring onto their screen...
]]>Those developers who have already left apparently did so with a good mood. They worked hard during this two days at the KDAB office (thanks to them for hosting us again!). It didn't even distract them that the office is right in the middle of a huge variety of restaurants, pubs and cocktail bars. There was a lot of more or less quiet hacking going on and I observed some vivid discussions about not so common topics. And of course I learnt some new things like doing a SWOT analysis, that it makes sense to arrive well rested and that wikis can look surprisingly pretty.
]]>We'll start at 7:00 UTC and gather on #kde-bugs to hunt down known bugs and find some new in the latest release. Let's make KOffice 2 the best and coolest office suite out there in the world and help the developers by providing the best and most useful bugreports we can come up with and cheer them on! If you can spare some time, don't hesitate to join us. You don't need any coding skills, a working install of KOffice 2.0 beta2 will do. But watch out, summertime ends tonight!
For more information please have a look at these articles on techbase: KOffice Bug Day 1: Triage KOffice Bug Day 1: Krush Thanks to the BugSquad for organizing this. :)
]]>In the early days, when I first came across the concept of the internet, usegroups and mailing-lists were entirely social. With broader acceptance of the internet itself, things changed to a more presenting approach. Content became statically available on websites and there was usually no way to interact with the owner of a site apart from email-forms. With all the buzz around a web2.0 built on the concepts of community and interaction between the users, things have changed again back to where the web came from for the average user. Web start-ups and companies now take a huge effort in building a community and turning their online services into a vivid place of exchange and interaction.
The idea I initially had at Akademy was to use the most known web services for KDE as a whole. This doesn't really work out due to various reasons. At least not yet. What I think would work instead is the use of the social web for KDE subprojects such as KOffice where I recently came up with this idea. We're preparing the new release and I suggested to create some buzz for it using web2.0 services. While discussing this on IRC or private chat, it occured to me that not everyone saw my intention behind it. The biggest advantage of those services mentioned above is the possibility to share and interact. What makes KDE stand out from the crowd is the strong liaison to its community and by using the social web we open new ways of participation to nearly everybody.
I will take KOffice as an example for my ideas. First, I would register an account on flickr for screenshots, one on blip.tv (as it seems to have some advantages) for screencasts and one on twitter to which I would feed all developers' blogs with the help of twitterfeed. Then I'd create an account on friendfeed and add all of the accounts I set up for KOffice and eventually already existing ones. With the help of this feed service, I'd get all activites on the various services collected in one place and made available via RSS again. The curious now only needs to monitor one single feed to get all the information available on the internet by the KOffice project and its developers.
Because it's all about sharing. By uploading the screenshots to flickr for example we make them available to everybody and allow comments on it, and by posting them to the right group within flickr we get impressive view counts. All services make us address people that might never have heard about KOffice at all (we all know how very often we stumble upon something we were not actually looking for on the net) and let them comment on or share the information. With friendfeed we take it even further. Everybody with an account there can forward parts of his subscribed feeds to friends or so called rooms and comment. If anybody in your networks is susbcribed to the KOffice feed and commented on a screenshot for example or liked something, you will see that in your feed, (My feed is here, have a look at it if it's not all clear yet.) With the right use of the technology available we can reach very far. And: everything collected within theses accounts can easily be embedded into the existing websites.
Someone will have to take care for the accounts and get material from the developers involved in the project. Only then it will be possible to keep the content fresh and the audience interested. If everybody puts a little effort in this and — for example — makes it a habit to take screenshots of newly implemented features or a polished GUI and then mails it to the account holder, it will keep the workload for everybody on a reasonable level. And now that you've actually made it to the end of this blog: thanks for reading! :) I would love to hear your thoughts and comments on this and officially open the discussion here.
]]>View SlideShare presentation or Upload your own. (tags: koffice2 kde)
]]>Claudia and I arrived yesterday around tea time after missing our connection at Zurich. Travelling by German Bahn always is an adventurous thing... especially when I travel to Switzerland.
During our slightly longer than planned trip I added the final polish to my talk which is scheduled for this early afternoon and wrote my thoughts on a *huge* staple of notecards. I was even asked if I did my homework on the train!
Due to pure coincidence my perfect timing I will give a talk on KOffice 2 right on the day of the first beta release. I somehow landed in the technology track which was quite a shock to me at first sight, but after making up my concept it seems to fit fine... I hope.
So keep your fingers crossed for my first tech-talk and stay tuned for the slides. They will appear soon after my talk sometimes this afternoon. If I have the time that is.
Oh and by the way, if you happen to be in the area drop by. We're at Eulachhallen, somewhere in the back corner close to a coffee machine.
Tags: kde, switzerland, openexpo
]]>[GERMAN] Desktop im Aufwind: linux-community.de
[GERMAN] KDE 4.1 erschienen: heise.de
[GERMAN] KDE 4.1 - neue Desktop-Generation für alle?: golem.de
[GERMAN] Interview: KDE 4 macht Fortschritte: golem.de
[GERMAN] KDE 4.1: Zahlreiche Verbesserungen für den Linux Desktop: derstandard.at
[GERMAN] Don`t look back: KDE 4.1 erschienen: kubuntu-de.org
[GERMAN] KDE 4.1 veröffentlicht: futurezone.orf.at
[GERMAN] Linux-Desktop im Aufwind: KDE 4.1 ist da: linux-magazin.de
[GERMAN] KDE 4.1 ist fertig: pcwelt.de
[GERMAN] KDE 4.1 veröffentlicht : pro-linux.de
[GERMAN] KDE 4.1 in Screenshots: pro-linux.de
[GERMAN] KDE kehrt zu den Massen zurück: silicon.de
[GERMAN] Neue Features für KDE: testticker.de
[ITALIAN] Speciale/KDE 4.1 si sente pronto: punto-informatico.it
[SWEDISH] KDE 4.1 ute nu - läs om nyheterna: idg.se
Tags: kde, community, getting involved
]]>Blogged with the Flock Browser
]]>Das ist natürlich Schmu, mit dem Projekt der Woche. Ich werde nie im Leben einmal in der Woche ein Projekt hier vorstellen. Allerdings war es das Gesprächthema am Küchentisch diese und vorige Woche. Mann und Sohn haben ziemlich viel Zeit damit verbracht, Nippes und das Agnesviertel zu kartografieren. Jetzt gibt es ganz viele neue Kioske und Bushaltestellen — wichtig für kleine Menschen - und (Einbahn–)Straßen, Häuser, Schulen, Park- und Spielplätze und Kneipen — wichtig für große Menschen. Die Ampeln stammen allerdings nicht aus dieser Vater/Sohn-Liaison... Wem nicht so ganz klar ist, wozu das nun bitte alles gut sein soll — abgesehen von sinnvoller Kinderbelustigung — dem sei die Wiki-Seite zum Thema GSoC 2008 ans Herz gelegt. Sehr interessant, was die da alles vor haben.
Blogged with the Flock Browser
Tags: openstreetmap
]]>Leute, fahrt mit der Bahn!
Tags: bahnfahren, kontakt, gespräche
]]>Blogged with Flock
Tags: antiquariat, start-up, marelibri
]]>Tags: linux, knoppix, sueddeutsche
]]>