squeakyvessel

My new site: cto.coffee

Mon, 11 Mar 2019 00:00:00 +0000

TL;DR This site will not be updated anymore. I now write and podcast at cto.coffee.

It’s not a coincidence, that the latest post on squeakyvessel is more than 15 months ago. And even then it was more of an event announcement than actual content (btw the workshop was great 🎵).

Because, since that time I started a podcast with the title cto.coffee, where I talk about humans in tech with varying guests. In the latest episode I talk about “Symbolic & Observational Thinking” with Yulia Startsev.

Plus, recently I also started writing on the same site, the first article being about how one can lead without formal authority.

So, if you want to keep up to date with my writing or are interested in listening to a podcast, then head over to cto.coffee, as this site will most likely not be maintained with newer content in a while. 🙂

Sonic Pi Workshop in Frankfurt

Wed, 20 Dec 2017 00:00:00 +0000

TL;DR register here for a free, evening-long, intro-level workshop “Live coding music with Sonic Pi”.

I’ve been enjoying all kinds of music, basically all my life. But somehow I never considered myself musical. I still somehow tried to learn an instrument (with very little effort actually going into that attempt), and failed. The barrier always seemed too high for me.

Even so, I couldn’t really shake the longing for being able to create music. That’s why the topic of Programming Music and the respective tools, as it being the combination of two things I enjoy, were something I tried to dip my toe into for quite a while now. But they always seemed too intimidating, the concepts too daunting, to actually try them out.

But all that changed during an evening session at this year’s SoCraTes.

During the first day’s session marketplace at the conference, I thought “fuck it, this is the safest space for me to reveal how clueless I am about programming/making music”. Which brought me to propose an evening session on Programming Music. I introduced the session with something along the lines of “I have no clue, but I want to spend time on trying out stuff, maybe others want to join me”.

As to be expected at a SoCraTes event, the people who joined me were knowledgeable, eager to share and absolutely wonderful, all at the same time. I went into the session with no knowledge about creating music and left having created some tunes with Sonic Pi and with no fear to do more.

Since then I couldn’t stop playing with Sonic Pi and learning more about music and music theory, which feels amazing.

And I now want to share that joy and show others, that the entry to creating music, being musical, is much lower than you think. Especially with a tool such as Sonic Pi.

Which I’ll do with this workshop and also at the Ruby on Ice conference, which takes place from 26-28 January 2018 at beautiful lake Tegernsee.

Workshop

The workshop is titled Live coding music with Sonic Pi and will contain a short introduction into Sonic Pi’s principles.

The majority of the workshop’s time however will be you playing and creating music, experimenting with music and having loads of fun. Trust me, after participating in this workshop you’ll have a new hobby.

Details

Workshop takes place on 22-Jan-2018 in Frankfurt/Main at the ioki office
Starts 18h / 6pm and lasts 3-4 hours
max. 15 participants
Free of charge … maybe there’ll be some snacks and drinks.
Workshop will be held in english (except if all participants agree on doing it in german)
Suited for beginners. No prior experience with Sonic Pi or creating music necessary or expected.
Experience with programming not necessary (but helpful)

You need to bring

Your own computer (ideally with Sonic Pi already installed)
Some headphones
Loads of curiosity

If you’d rather like to collaborate with someone during the workshop on the same computer I strongly suggest using a so-called y-adapter, so both of you can has their own headphones.

Register

The event is already over and you can’t register anymore.

My New Chapter, My New Role

Thu, 09 Mar 2017 00:00:00 +0000

So here I am, finishing up my second week in my new role, after leaving my last job.

My New Role

The last days already contained the to-be-expected mix of exhilaration, excitedness and strain (the good kind) from trying to cram as much things into my head as possible in a short amount of time.

My new colleagues are the people from Crispy Mountain. Right now, we’re working on Keyline, which can be described as Software-as-a-Service that functions as the brain and backbone for printing companies.
We are located in Mainz, and totally incidentally right around the corner from my favorite coffee shop. Right now I’m commuting every day, but will transition to several days remote working per week, once I feel I need less support with all those tiny, magic bits of Rails.

My Last Weeks

Before I published the blog post, I shared it privately with some people. One of them asked me if I set aside a day for answering all the messages I’d get. Back then I thought he was joking, but soon realized that I underestimated a lot of things. Beginning with the friendliness and number of people who shared my search and wished me well. Thanks so much to you all.

It continued with the amount of interesting things happening around me. And the trust people put into me, when approaching me with their endeavors and assuming, that I could be a meaningful help for them. That assumption of competence was really humbling, and a great privilege (being the white man that I am). Still I’m thankful for having had as many chances and interesting conversations as I had in the last weeks.

… all that while wrapping things up at vaamo. And about that：The people at vaamo, not the least their new Head of Engineering Timo, really helped me make time for all these conversations. Thank you! And thank you, dear awesome vaamo team, for a great farewell party and these amazing gifts

Super-Mega-Duper-Special-Thanks to Sebastian for making these great guides and cards.

Oh, want one of these brew guides? Ping me and I’ll send you some. They actually gave me a huge stack and not only one of them.
And did you notice that cto.coffee at the bottom?

Why Crispy Mountain?

You mean, that name and logo wouldn’t have been enough to convince you? Well, I can’t fathom why, but still there are more reasons for me, why Crispy Mountain is the perfect choice for me right now.

One of them is: They’re people who care about people.

I had several contacts with Crispy Mountain before already, be it an occasion to work at their lovely office or meeting Christian at a Techettes meetup, where I learned about the fact, that he coached at a local RailsGirls event and at one instance of RGSoC. In all these contact occasions I experienced them as friendly, considerate and smart people.
And talking to them several times over the last weeks, confirmed and strengthened that image.

Another reason is their approach to product development. Not only because of their team size, but because they believe it, Crispy Mountain has a no-bullshit¹ approach to developing Keyline and working with customers on eye level and in a productive partnerships². I experienced it from day one working with them and cherish it a lot, that it’s not just lip-service.

Last and not least is the fact that Crispy Mountain gives me the opportunity to dive into a new-for-me technology, as their products are mostly based on Ruby and Rails.

I’ve wanted to work with Ruby for a while now, which for me also means to get to know the Ruby Community, which I perceive as one of the friendliest and open programming language communities out there. So I’m looking forward to expanding my horizon not only technically, but also people-wise <3

In any case: If you want to know more about Crispy Mountain, got some nice Ruby hints or links for me, don’t hesitate to reach out and tell me about it.

Fun fact：Relatively soon after publishing my blog post, Matthias contacted me, more or less with an invitation to their slack team. That is, we exchanged one email, and all subsequent conversations happened via slack. Talk about no bullshit-attitude. ↩
Diligent readers will notice my sneaky but deliberate reference to the Software Craftsmanship manifesto right there. ↩

I'm looking for a new opportunity

Mon, 16 Jan 2017 00:00:00 +0000

Update: I found a new role and wrote about it

What’s next
What I’m good at
- Technology
- People
What’s important to me
What I would love to do
- Building Teams
- Tech Evangelism, Developer Relations

It’s been quite a ride, the last four years.

Almost exactly four years ago, on the 14th of January 2013, I met Oliver Vins at #wmfra. He was not one to overlook, as he wore a bright yellow T-Shirt proclaiming that he and his co-founders were looking for a CTO to join their, then-to-be-founded, startup vaamo [now defunct].

On that evening I never expected to actually work with them, much less spend the longest time yet at a job, at that company, with Oliver and Thomas (the other co-founder).

Still, that’s what happened and looking back, it was one of the best decisions I’ve made in my life.
For the last four years I’ve been the CTO of vaamo. In that role I’ve been privileged to work with the brightest, kindest and most awesome people I’ve ever met and worked with. Together we’ve built a robust and scalable company and product, while never losing our kindness and respect for the fact that we’re all humans. I’m incredibly proud to have helped shape a company and culture that keeps on delivering with a sense of calmness and humanity.
Looking back it was my first “real” management job, and I’m incredibly lucky and happy that Thomas and Oliver trusted me and gave me the opportunity to be part of and shape that roller-coaster-ride that is a technology startup.

Then again, after such a long time (long for me) I feel it’s time to do something different. And so: I’m open for new roles and opportunities in the next months.

What’s next?

Currently I’m quite open about where I am going next. Freelance or permanent position. Both is possible.

I can imagine to join a company in a permanent role, and I think some of the below described aspired roles, are likely only available in permanent positions.

Then again, when it comes to company culture and degrees of freedom offered in a position, vaamo set a very high bar for any future job of mine. So I can imagine to take on freelance/contract work for the foreseeable future, if a fitting permanent role is not in sight.

All that said: Contact me if you think my skills and strengths could help you. Whether it’s freelance work or a permanent position, we’ll work out the details while talking.

What I’m good at

Technology

Technology-wise I’ve always been and still am a generalist. I’ve worked on a wide range of products, in different roles and several industries. I have strong opinions, that are weakly held, about how to do Frontend as well as Backend development, and also how to operate software in production.

Through my more than 15 years experience in tech, I’ve acquired the ability to quickly and intuitively grasp a breadth of situations and can usually assess ways to move forward reliably. This served me especially well, in roles where I was at the intersection of tech and business, which roughly was the last eight years of my career.

And just to be clear: Yes, I can code. And I still code. That is, if you’re looking for a very experienced developer, who contributes code and goes beyond, then let’s talk.

People

People first, all else will follow.

I care about people. I care about people to bring their best self to work, if they choose to. I care that every person in a team is able to contribute according to their strengths. I care about helping people grow, be it their career and skills, their contentment, their happiness or whatever they choose.

Also I’m good at listening. To what peers and customers are saying, then tailoring solutions to their actual needs. That usually means I bring people together, facilitate discussions and help people reach meaningful conclusions and decisions.

What’s important to me

People

And: People.

I believe, one of the reasons I consider myself “good” at working with people is, that the people I work with are important to me.

That means, I’ll patiently point it out, whenever you use the word “resource” when you’re actually talking about a group of people. So, when you see people only as a means to get a job done, and not as the actual goal, then we’re probably not a good fit. If it’s not in your genuine interest to make the life’s of those around you better, then we’ll probably not work together for long.

Freedom to choose time & place to work

I’m a dad to two wonderful children, and a husband to an amazing teacher and school vice-principal. That means I got responsibilities, in addition to my professional work. In order to fulfil my duties and responsibilities adequately, I need a certain degree of freedom when it comes to where and when I do my work.

In addition to that: The centre of our life is Frankfurt, and I’m not willing to change this. So in order for us to work together you must either be in the Frankfurt/Rhein-Main region, or be ok with me working remotely most of the time.

Diversity

I think the tech industry is broken with regards to, how it knowingly (and unknowingly) excludes larger groups of people, based on stereotypes, biases and seemingly “best practices”.

This does not mean, I don’t want to work with you, if your code fails the Bechdel-Test. Rather it’s important to me, that people I work with are willing to reflect their own behaviour critically, and how they might be part in excluding people. And in the end change that behaviour.

What I would love to do

Building Teams

One of the greatest joys in the last years was my work to build a team, to find people to join the team and work with all of them to make it the best team they can imagine.

And I’d love to help others do similar things. That means, working on the intersection of HR and tech. Helping grow scalable teams. By finding and hiring the right talent and helping to shape meaningful practices and team culture. A culture that not only puts the people’s talent to their best use, but also makes it the best place to work for the people on the team.

I can imagine doing this in a supporting role, as a consultant. And I can imagine making this my main focus of my work at a company, that’s growing its team and wants to ensure the longevity of its measures.

Tech Evangelism, Developer Relations

Through my work at vaamo and my involvement in several communities, before and while being CTO, I’ve really enjoyed bringing people together. The actual team at vaamo of course, but also reaching out to people outside the company, connecting with a broad range of communities. Putting together groups that as a whole are better than their sum of its parts. Most of the time while doing that, bringing together such groups, I’ve observed the side-effect that people discover new ways to grow, that have been unknown to them before.

And while I haven’t held a position like Developer Relations and activities such as Evangelism/Advocacy/etc were only a small part of what I did as vaamo’s CTO, I enjoyed this part of the work immensely.

That’s why I’d be excited to help a company or team reach out to and become a part of the wider tech community (or a specific subgroup).

Hire me

If you’ve made it here, you seem to be really interested in what I do. Come on, reach out, write an email to benjamin@squeakyvessel.com.
Whether it’s freelance work or a permanent position, we’ll work out the details while talking.

Engineering Ladders Linklist

Mon, 11 Jul 2016 00:00:00 +0000

Sometime in summer 2015, when preparing yearly feedbacks for my team at vaamo, I started formulating our team’s (engineering) ladder. Back then the concept of a ladder, the act of spelling out what the requirements and expectations for a specific role and position are, was pretty new to me. Still it immediately appealed to me.

The first ladder I came across was Rent the Runway’s Engineering Ladder as shared by RTR’s CTO-at-the-time Camille Fournier.

And while working on vaamo’s ladder I came across many more ladders, many of them inspired by RTR’s ladder, or inspired to be shared by RTR’s sharing.

After a while, keeping tabs on all those published ladders became nearly impossible. Yet, I found it very inspiring and helpful to have a list of resources in the spirit of “that’s how others do it”, in order to pick and choose what works best for our case.

So in order to make it easier to get inspired by other companies’ engineering ladders, I decided to put together a complete list of all published engineering ladders.

When using any of the below ladders as a starting point, be aware, that you’ll need quite a bit of effort to adapt and develop your own understanding of what the roles’ and positions’ classifications mean for you and your organization.

Ladders

Rent the Runway
Artsy
Travis CI
Kickstarter
Urban Airship
Intent Media
Spotify
Charles Krempeaux
Fog Creek
Cap Gemini
Patreon
Songkick
Medium
GOV.UK
Tes Global
SkillsMap.io
Buffer
Meetup
Soundcloud
progression.fyi
CircleCI
Square

If you’re aware of a ladder, that’s shared somewhere but not on this list, please contact me or send a pull request.

Rent the Runway

When looking at some of the other ladders, this is the one that kicked off many if not most of them to be shared.

I find it very well structured, approachable and it reveals deep thinking behind it. I especially liked the concept of the four pillars “Technical Skill”, “Get Stuff Done”, “Impact”, “Communication & Leadership”.

Artsy

The ladder from Arty’s team, as shared by their CTO Daniel Doubrovkine has a much simpler structure than the RTR ladder, even though it says it’s much inspired by it.

Travis CI

The newest ladder on this list, was only introduced on 24-Jun-2016 at RedDotRubyConf in Singapur by Travis CI’s CTO Konstantin Haase.

While the ladder itself is not overly prominent in the slidedeck and video, the reasoning and story behind the compensation framework, which is based on the ladder, is very interesting.

Kickstarter

Kickstarter’s engineering ladder, as shared by James Turnbull, features paths for Technical and Data people as well as People Management roles.

Each role and position, up to the CTO, is described in helpful and concise prose.

Urban Airship

Urban Airship’s ladder covers engineers’ and operations’ paths as well as the respective manager ladders.

Similar to RTR’s ladder, Urban Airship’s organizes the expectations towards each engineering and ops level around the concept of four pillars, namely “Domain Knowledge”, “Teaching and Mentoring”, “Culture and Leadership” and “Customer Success”. Notice the absence of anything “Technical” from this list of pillars. Management positions are described using three pillars “Scope and Impact”, “Team Development” and “Customer Success”.

Intent Media

Intent Media divides it’s engineering organization into three paths, namely “Team Contributor”, “Technical Leadership” and “Engineering Management”.

It provides a lot of context about how engineering in general is structured at Intent Media and all positions are described in a concise yet extensive prose. It’s very well structured, offers a lot of inspiration and conveys deep thinking that lead towards the ladder.

Spotify

Spotify documented their way to something like an engineering ladder, then wrote about how the v1.0 looks like and lastly shared their lessons learned and surprises while introducing the ladder.

Very interesting and comprehensive read and bonus points for providing a very different approach to an engineering ladder, than most others in this list.

HT to Robert for sharing these links with me.

Charles Krempeaux

Charles is CTO at Koho and shared his ladder. “His” in the sense of “no company is specifically mentioned in the blog post”.

It’s extra helpful, as it contains specific reasoning in which circumstances titles are helpful or maybe even necessary, and why it’s a bad idea to have a ladder where the top technical level is something like “Senior Software Engineer”.

Fog Creek

Honorary mention for the infamous ladder by Joel Spolsky which dates back to the year 2009 and is probably one of the first publicly shared engineering ladders.

Compared to the more recently shared ladders, it has a completely different approach and is the only one in this list, where “years of experience” is a measure of sorts. Which in my opinion, simply isn’t appropriate anymore. Go watch Konstantin’s explanation of how a better way to think about an employee’s value contribution to a company looks like.

So just to be clear: Don’t base your ladder this one, as there are better ways to arrive at compensation levels than “years of experience”.

Cap Gemini

Last year, we identified a need to redefine the career framework for our software engineers within the UK engineering teams and started work on a Capgemini Software Engineering grade ladder. The grade ladder is our team’s self-produced documentation to enable everyone, both inside and outside our team, to understand our ethos and values and what’s expected of them.

Patreon

Today we are excited to share Patreon’s revamped Engineering Leveling Guide. In Patreon’s early years, we had little in the way of objective criteria for leveling engineers. We’ve come a long way since then, and our engineering organization is much stronger and fairer for it. We want to show you how we define levels now and what it’s like to work at Patreon.

Songkick

Songkick’s Career Growth Framework is very detailed and beautifully designed. It’s a great resource and inspiration to anyone looking to structure career growth at a team. As many other ladders out there already it describes a management and a technical career path.

Medium

Medium’s ladder is very comprehensive and therefore more than merits the title “Growth Framework”. The frameworks aims to help engineers answer the question “How do I progress?”. Medium offers 16 different tracks that each are organized into the categories building, executing, supporting, and strengthening.

The framework includes a description of tracks and the process how people at Medium assess their progress. A notable distinction from other ladders is the “appeals process”.
The Growth Framework describes it with the following words:

Given that the framework is somewhat subjective, we accept that even reasonable people acting in good faith can make mistakes or fail to appropriately value work. The appeals process outlines the way in which engineers can challenge a decision they consider to be inaccurate.

GOV.UK

The government of the United Kingdom released perhaps the most comprehensive career ladder/growth framework available. The skills are entirely generic so will require a degree of effort to reduce subjectivity and ensure consistency of interpretation. It covers an astonishing 38 different data and technology roles including management and technical tracks for many of the roles.

Anyone can use the Capability Framework to:

learn about what different roles do in government

understand what skills are needed by professionals in particular jobs

identify skills that need development to help career progression

assess skills in preparation for performance reviews

create effective job adverts

carry out HR and workforce planning

Tes Global

Tes Global designed their engineering ladder differently than most of the others. Rather than using career levels, they use a modified Dreyfus model to show skill progression within a set of high-level categories. Career levels can then be laid over this map to provide more flexibility than most other engineering ladders. The original and the evolved map, which has acceptance criteria for each skill, provide an idea of how this worked in practice. There is also a talk by David Morgantini that explains in greater detail how this engineering ladder was used at Tes.

The downside to this approach is it is more complex than others and requires tooling support and does not scale past 10 - 15 engineers without such. Tes implemented and open-sourced a tool to manage this kind of ladder.

SkillsMap.io

SkillsMap.io is not a engineering ladder itself, but rather, a tool that allows teams to build their own engineering ladder. It emerged out of the engineering ladder created at Tes Global, and is a fork of the open source tool they released in late 2017.

The tool provides:

a structured and scalable evaluation & review process
the ability to create custom skills maps or engineering ladders
skill gap reporting & insights
the ability to evaluate candidates prior to interview

In Aug 2018 I talked to David Morgantini, the founder of SkillsMap.io, about career growth frameworks and engineering ladders on episode 04 of the cto.coffee podcast.

Buffer

Buffer’s ladder (published early 2017) is not a ladder. Instead Buffer chose to use “scope of influence, together with a description of ‘how work is conducted’, [as a proxy] for technical skill.”.
I think it’s a very interesting and great step forward, from the earlier, more rigid ladders.

Meetup

Meetup shares their cross-company set of rules and expectations for Makers and Managers within the company. It’s very comprehensive and knowing that Lara Hogan worked with Meetup on it, let’s you know, that it’s well thought out and a great resource.

Soundcloud

Soundcloud released their engineering ladder beginning of 2018, and even though they stick to the now almost classic model of several dimensions (skills and behaviours), the description reveal that they put a lot of effort and thought into it.

progression.fyi

Progression.fyi is a project by Jonny Burch and is not a ladder or progression framework in itself, but rather a nicely-tagged and better navigatable collection of such. Due to Jonny being a designer, the collection features a lot of non-engineer ladders, which may give a little extra inspiration and ideas to those who seek it.
Plus it lists even more ladders/frameworks than this page.

CircleCI

CircleCI released their engineering competency matrix at the end of 2018.

Square

Square released their engineering career ladder in July 2019. It features separate tracks for individual contributors and managers. A noteworthy detail in their ladder is that they label some of their criteria and responsibilities as shared between managers and ICs.

Missing a ladder?

If you’re aware of a ladder, that’s shared somewhere, please contact me or send a pull request.

Lots of 😍 to the following contributors so far:

Farewell Leader's Digest

Tue, 15 Dec 2015 21:21:00 +0000

The following email was sent to the recipients of Leader’s Digest newsletter, which I curated for the award-winning streak of five weeks in a row. Why did I stop? Read on.

Goodbye everyone!

Whoever kept track on the number of time this newsletter was sent out, might not be surprised. The lack of sent-outs over the last week c ombined with the number of times it was actually sent, I can safely call this newsletter to an end.

I struggle to call it failed, because for me it helped me get one step further towards understanding what it is that really want to do. A nd smart-assing about how to do “leadership in tech” the “right way” is not one of them.

What I’m really interested in is having more fulfilling interactions with people, and that includes interactions at work.¹

And I’m on a journey toward bettering and clarifying my own understanding on how to achieve that.

If you’d like to hitch a ride on that journey, you’re more than welcome to join me. Follow along on my blog, where I’ll post (probably irregular) updates to my understanding and thinking about this topic, or follow me on twitter, where I’m @benjamin.

Though I’d appreciate it even more, if you reach out and give me a glimpse of how you think about it. Do you think it’s worthwhile to work towards more fulfilling interactions, also at work? Why? And what’s your current approach to have those? And in general, how can we do better than this right now? Reach out to me, by replying to this email or contacting me via my website’s contact form.

Cheers, Benjamin

I “managed” the newsletter and the planned links on a Trello board, which you might find interesting, if you’re looking for interesting links.
Also, the archive of the sent-out newsletter issues are here

Where more fulfilling means more than just being nice and making everybody happy and all warm and fuzzy inside. It’s about making that what makes us human, interactions between each other, more long-lasting and meaningful for but also beyond those involved. ↩

On the Structure of One on Ones

Wed, 09 Sep 2015 23:20:00 +0000

This is a continuation of my previous post, in which I covered the goals and purposes of One on One Meetings

Prepare - Choose a Theme
Listen
Status Update
Conclude with Something Actionable
Dream Big
How Long is a 1on1?
TL;DR

Over the course of those last two years, I found a structure for having 1on1 meetings that helps me a lot to get the most of these meetings, and which also helped to make 1on1s a deeply ingrained part of vaamo’s tech team culture.

Structure

All of the below elements, can be used on their own and you don’t necessarily have to do all of them in every meeting. But of course to some extent, used together they are stronger than each of them is on their own.

If you’re starting out doing 1on1s with your team, I suggest you start out with one element only and over time add more elements.
They’re ordered in a way that each element builds upon the previous ones and expands them in a sensible way.

Prepare - Choose a Theme

While some posit that 1on1s are the employee’s meeting and I’d generally agree with that statement, it’s your job as manager to have your team member’s back and make sure the 1on1 is useful in any case.

Photo under "CC BY 2.0 License" by Photo Monkey

By that I mean, you should at every point in the 1on1 be able to take the lead and steer the meeting into a direction that’s useful to you and your team member. Proper preparation can enable you do to that.

What worked very well for me, is to set a theme beforehand. Think of a theme that gives you both valuable insights.
Have you talked about how the team could improve lately? Do you know who your team member thinks is doing a great job on the team? Why? Do you know what they think of your management style? Do you know where they’d like to be supported more? Do they have a grasp on where they’re going with their career?

Having a regular direct line to your team via 1on1s is a powerful tool to get an intimate view into the opinions of your whole team. By setting a theme and asking everyone the same or a similar set of questions in their 1on1s, you can get a good picture of how your team feels about certain things.
In my recent experience, it was immensely helpful to know what made everyone on the team feel productive, by asking everyone in their respective 1on1 the same set of question, which was “Do you feel productive in your day to day work? What makes you feel productive?”. The answers enabled profound changes and increased happiness across the team, and event after quite some time now still prove very helpful in designing processes.

Jason Evanish has an exhaustive list of questions for 1on1s, so does Lara Hogan who has a great list of Questions for your first 1on1. Popforms even provides a service to deliver a set of matching inspirational questions to to your and your team member’s mailbox at a specified interval.

Listen

This is somewhat an antithesis to the previous structuring element, but nevertheless very if not more important.

Photo under "CC BY 2.0 License" by Matthew G

You, as a manager, should spend most of the time listening to what your team member has to say. And by listening I mean to really try to understand what the other person is saying, by putting your own definitions and opinions into the background.

Look out for moments where you’re waiting to release an already prepared answer to whatever your counterpart is saying at the moment, while they’re still speaking. In those moments you think you know what the other person is saying. But really all you’re doing is reacting to your pre-defined notion you have about the other person.

Status Update

An important purpose of 1on1s is to get to know your team members’ views and feelings about various things. And among “those various things” are also, let’s be honest, current projects and tasks.

Photo under "CC BY 2.0 License" by Pedro Ribeiro Simões

Everybody says “don’t use 1on1s for status updates”. But sometimes that status is the thing that’s on everyone’s mind. So it’s simply not practical to not exchange that update.

The most sensible thing you can do, is to make that update useful. Which in my experience is done by limiting the time you spent with this update and by getting the unique perspective of your counterpart on the subject. Make sure you don’t spend time on defining and discussing concrete actions about the current work, that should be postponed to be done later, even if directly after the 1on1.

So, don’t be too dogmatic on your definition of 1on1s but rather make sure it’s useful for everybody.

Conclude with Something Actionable

The temptation is high to end the meeting, when you both feel there’s nothing left to say. You possibly exchanged your views, at least you listened and deepened your understanding of some area. You’re feeling all fuzzy, because everything’s great. You’re awesome, your team member is awesome. And that’s it.

No! Don’t do that.

Photo under "CC BY 2.0 License" by Steve Slater

Take those extra 5 minutes if you will and decide together what the next action for each or both of you should be. How can each of you make the next minor step to improve one of the possibly many topics that was touched upon in that specific 1on1?

Ending the 1on1 with some concrete actions, something that you can both be held accountable to, is super important. Because it will bring constant progress into your relationship with your team member. It will be one of the most natural things for both of you, that over time you keep on making things better for both of you.

But the rhythm of constant smaller actions, is also a great tool for building trust. By constantly “showing up”, delivering on the agreed actionables, trust will become a natural part of your relationship with your team member.

Dream Big

Having 1on1s and with this a regular point of contact, you and your team member have a venue for working towards a larger, possibly far away personal and/or career goal.

Photo under "CC BY 2.0 License" by Kai Lehmann

In most circumstances the product and what the company wants to do and achieve is more or less well taken care of and worked towards. But when a single team members personal development and career goals (or at least a direction in which someone wants to go), it’s hard to place it somewhere it receives continuous progress. And the rhythm allows you to chip away at this far-away looming mountain of work. One step at a time.

Hot Topic: How long is a 1on1?

One of the minor but constantly asked-first questions about 1on1s is about the length of the meeting. “How much time should we spend on the 1on1?”

Photo under "CC BY 2.0 License" by valentin.d

Obviously the only right answer is a “depends”.

I’ve read a lot of articles over time, where people mention 30min per 1on1 with a weekly or bi-weekly schedule.

Personally I prefer longer but slightly less-frequent 1on1s, and currently my 1on1s are 1h long and we do them bi-weekly. I prefer this schedule, as I feel that some topics, especially the hard ones, need time. The really interesting stuff always happens sometime into the meeting, when people become more relaxed. But that may very well be related to my personality, as I’m more the kind of person who likes to take it’s time with hard topics.

TL;DR

If you’re not doing 1on1s yet with your team, I strongly encourage you to start doing so. And if you’re not sure yet, take a look at the why behind 1on1s.

When starting out, begin with only a few practices outlined above and extend over time. Time is on your side when doing 1on1s. If you stick with them, you’ll have lots of iterations soon and can expand and play with the format sooner than you think.

On the Purpose of One on Ones

Thu, 21 May 2015 11:38:00 +0000

I’ve been leading teams for little over seven years now. Almost right from the beginning of that time I reserved timeslots, to sit regularly & privately with each of my team members. My motivation back then was to give every team member a regular opportunity to tell me what’s bothering them.

Looking back, that motivation was deeply rooted in the most common emotion I had in my job at the time, and which I assumed all others had too: Frustration.

I assumed what people needed most was a place to vent (thanks rands, for that nice word) and the feeling of being heard. It took me some time to realize I wasn’t using that private time with my team members to it’s fullest potential.

Since I started working at my current role (ed. CTO of fintech startup vaamo) two years ago, I started to give the purpose and structure of those private meetings more thought. You could say, I started doing 1on1s according to a currently predominant definition¹.

Below, and in a follow-up post, I’ll share what set of goals and which structure for 1on1s worked well for me.

Purpose

Ask a manager what they think are the goals of 1on1s and you get a different answer everytime. This one is probably no different.

For me the purposes of 1on1s are manifold, but they all revolve around: Create trust! Between you and your team member.

Build a relationship

Trust can only exist in a relationship. So, the first step towards building trust is building a real relationship with your team member. One where you’re really interested in the opinions and feelings of the other person, and not the least the person itself.

Actually, in the beginning I thought 1on1s were about having a deeper, real, human relationship with the members of your team.

And while of course this is not wrong, it’s not the whole story. After a while, I realized, that the purpose of having this relationship is to put you, both yourself and your team member, into a position where you can trust each other.

Provide a safe space

Over time, trusting each other will turn into something really beautiful: Your 1on1s will become a safe space. Again, for both of you.

This safe space will enable both of you to bring up every topic you chose. It will enable you to sometimes give the inevitable not-so-positive feedback that your team member should hear. And it enables your team member to do the same. To tell you when they think some things aren’t the way they should be.

Having this safe space, puts you in a position to fix problems when they’re still small. Instead of having to fight those big fires that can bring on a lot of trouble.

Long-term Goals and Career Development

Having a safe space and trusting each other is the perfect foundation to talk about the long-term goals and the ways your team member wishes to develop their career.

And you should use that foundation. It is a powerful building block of making your team member happier, making sure they feel they make progress toward something that’s meaningful for them in the long run.

In the end, also towards retaining them as a member of your team.

Continuous Improvement

Once you care about the long-term and career development of your team members, you’ll need to make progress on it.

Not only, because of the Progress Principle:

By supporting progress in meaningful work, managers improve employees’ inner work lives and the organization’s performance.

There’s nothing that boosts your team members’ happiness and productivity more then perceived progress, no matter how minor.

This means, one goal of your 1on1s should be to enable continuous improvement and progress. Your 1on1s can be the rhythm that will make progress and improvement come almost naturally.

Give Feedback

I’ve stated it above already, but this deserves to stand on it’s own.

One goal of your 1on1s should be to give honest feedback to your team member. Simple as that.

Why in a 1on1 and not during your normal working day? Because there are more than enough reasons and circumstances where it’s not appropriate to give feedback right away. Be it, that your team member might feel embarassed by the feedback, or that you simply don’t feel there’s enough time right at this moment to give the feedback fully and properly.

Structure

I’ll share a structure of 1on1s in my next post. You could say, my way of doing 1on1s.

… to be continued.

Possible definitions, even if they’re not meant as definitions, are such as “Manager’s Guide: How to start one on ones with your team” on getlighthouse.com and “The best 30 minutes you’ll spend this week: how to do a one-on-one that really counts” from popforms.com. ↩

Mature Developers

Tue, 12 May 2015 21:28:00 +0000

Some time ago, as I started to spend more time on growing our tech team at vaamo again, I realized that I had put off one thing for much too long already: Putting down my definition of maturity and technical leadership in software teams.

In order to get this finally sorted out, I’ll lay out the aspects that together make up a mature developer.

What Defines a Mature Developer?

A developer’s maturity is mainly defined by their soft-skills, less so by their technical abilities and knowledge.

The assumption underlying this postulate being, that it’s very unlikely for a person to combine most of the below mentioned maturity traits without going through some years of working in teams, in which the technical skills will likely get sorted out one way or another.

But what actually are those characteristics, soft-skills that make up mature developers?

Mindfulness

Mindfulness is a simple practice that can be described as paying attention to what is going on in the moment, without judgment.

And I strongly believe there’s a meaningful correlation between one’s ability and willingness to pay attention, to self-reflect and their ability to improve themselves and those around them.

So one of the first and most important qualities of mature developers is they’re more often than not paying attention to what is going on around them. They’re deliberately taking their time to observe before proceeding (put succinctly as STOP; Stop, Take a breath, Observe, Proceed).

Mature developers are being mindful about themselves and their surrounding, in order to be able to always keep improving their own work and approaches, and of those around them.

Mindfulness sooner or later leads mature developers to become aware of, learn about cognitive biases and find ways to handle them.

Curiousity

Technology work is creative work. And I simply can’t imagine someone being good at it, by any measure, without being curious. Curious about the surrounding technology, about how things work, about why things are the way they are etc etc.

And this curiousity should not diminish over time. Rather it should always grow alongside maturity, as one is exposed to more problems, technologies and people over time.

And it’s also important that this curiousity is not limited to technical topics only. Mature developers are curious about people, how they tick, what’s interesting to them and much more.

Pragmatism

The necessary counter-balance for curiousity is pragmatism. As one is curious about almost anything, they usually need to choose quickly about what’s important and when it’s important.

More generally, a pragmatic developer weighs possible options in terms of long-term impact and costs vs short-term benefits.

However, what’s hard about this skill, is that it’s very much driven by intuition. After some amount of experience, one has a basis to which current decisions can compared, in order to decide for outcomes that are less likely to work vs those that have a higher chance of success.

Pro-Activeness

Personally my first and still trusted indicator of a good developer is pro-activeness.

Someone who is pro-active communicates early & often. When discovering new information, learning something new they think about who this new information affects and act on it.

Furthermore pro-active developers seek out risks, they see chances way before they are obvious for others, which can help a team succeed much faster and more easily.

Where should the systems that people are working on lead to? How do you know it’s a success? What’s there to do, beyond the obvious stuff, that’s needed to get features out the door in the next three months and beyond and what’s the thinking and reasoning behind those visionary aspects?

Not the least part of having this technical vision is then also to actually share it with relevant people. Ideally with anybody who is even remotely involved in working with or shaping the system in the future. This means people like product managers etc should also know about the vision.

Sharing the vision with other involved parties not only serves as a perfect opportunity for practicing one’s skills to explain deeply technical terms and circumstances with non-technical people. It also serves the purpose to validate the vision in terms of relevance to business value and other aspects.

Understanding Business Value

Mature developers know and understand at every turn, that everything they do serves the purpose of providing value to someone else, most of the times some kind of business and with that, some kind of customer.

They’re able to put everything they do into a greater context of their business and understand how their current and future actions play out into this context.

Because of that they can empathize much better with non-technical people. Which in turn enables them to communicate and explain their actions and motivations more easily and usually concisely to non-technical people, and reduces friction when working with non-technical people.

Reasonable Risk-taking & Decisiveness

Putting their actions and plans into a bigger, non-technical context also enables mature developers to better assess risks. For example, does the risk of introducing a new technology possibly outweigh the business benefits that are to be expected?

Assessing and understanding risks better puts them into a position where it’s also more likely they’ll actually take risks. Risks which, without the knowledge about business value and the bigger context, may look too big to be worthwhile. But not for mature developers who are able to see beyond the obvious risks and include more aspects into their judgement.

Reasonable risk-taking furthermore involves excellent communications because assumptions must be made about the intended outcome of risk taken, and incomplete data leading to the decision for taking a risk must be accompanied by another set of assumptions. Mature developers, know that both kinds of assumptions must be communicated to others in order to raise the chance for the risk-taking to be worthwhile.

Lastly the ability to take reasonable risks requires a certain amount of determination, of decisiveness. Because while it’s all nice & easy to theorize about decisions that involve risks, at some point decisions need to be made on incomplete data, on assumptions. And mature developers must be comfortable with that. Mature developers have to like making decisions.

Empathy

Empathy is noticing, and better even knowing, the situation another person is in.

And it’s really is one of my favourite words and concepts. Without empathy you cannot be effective or even successful in working together with others.

You need to be empathic to resolve more conflicts than you create and therefore providing value to and with others. So empathy is an absolutely required skill for mature developers.

Empathy enables understanding others’ goals. But before that, one must have a real interest in getting to know their peers. What is it that motivates them? What do they get passionate about? What makes them happy? What frustrates them? Knowing those things about someone actually means having a somewhat real relationship with that person. And that is the basis for empathizing with them.

Without a relationship with that other person, you can still try to know about someone else’s situation, but you’re making assumptions at best if you don’t know the other person. And your assumptions will be wrong. Probably more often than not.

Another aspect which makes empathy an easy concept in theory but more complex in reality is, that it can and is easily mistaken with sympathy. Sympathy is empathy plus actually feeling the other person’s feelings. Which is not always helpful. It may even be confusing, because it may reinforce your belief that your assumptions about another person’s situation are correct. (h/t to Oren Ellenbogen for making this distinction clear to me)

Excellent Communicator

I’ve touched on mature developers being good communicators earlier already, but of course this deserves to stand on it’s own.

Mature developers communicate excellently by always taking the context of their communicating peers into account. They know or at least have a sense about their counterpart’s goals, their state of mind, sometimes maybe even the mood they’re in, and how their peers usually communicate.

This allows them to consciously choose the way they communicate with others. Does my counterpart need a direct and quick answer, or do they want to understand the surrounding details? Do they want a short answer now, but more info later on? Is it useful for my and my counterpart’s goals to take a more defensive stance right now, in order to relax a situation?

Put simply: Always know what your counterparts need and want to know. And deliver it.

When taking into account the context of your communicating peer and the situation you both share, one important detail often gets overlooked: Assumptions.

Making your own assumptions explicit towards your counterpart, asking for the other’s assumption usually makes communicating so much clearer. Not only faster by reducing possible misunderstandings, but also less of an effort and possibly less stressful, because with assumptions laid out the communication can focus on what’s to be done, and less about establishing a common understanding first.

Other Opinions

As with most things, many people have come before me and shared their view and they influenced my thinking or helped me shape my own way.

And rather than thinking my definition above is new or novel, you can view it as a prioritized extract and sometimes slight rewording of those originals. So when describing my own understanding in the above paragraphs I haven’t pointed to the exact references anymore. I’ll leave it to the interested reader as an exercise to find out where exactly I copied from.

The most comprehensive and absolute must-read on the topic is John Allspaw’s “On being a Senior Engineer”. It’s not only a testament to an amazing amount of clear thinking on behalf of the author, but is amazingly comprehensive and already a timeless classic. And I owe John Allspaw’s writing a lot, in that it broadened my horizon and gave words to a lot of things that were only unconscious before.

Some much more recent pieces on the topic of Tech Leads such as “Good Tech Lead, Bad Tech Lead”, “No Tech Lead”, a lot of stuff by Pat Kua and the ever-excellent “Leading Snowflakes” by Oren Ellenbogen they all provided loads of inspiration.
As well lots of very good reads from Kate Madsudeira as well her timeless talk on leveling up your engineering and operations role.

Of course, many more opinions, such as talking with my colleague Timo, with members of the local Softwerkskammer and at many a SoCraTes conferences, influenced my thinking, but those are the most prominent ones.

Reading in 2014

Wed, 18 Mar 2015 20:40:00 +0000

2014 was the first year, that I consciously set myself a reading goal. Although I knew it was a bit ambituous, I couldn’t bring myself to throw something out. I figured I’d prioritze over the year. And it kinda worked out well.

And of course, when you set yourself a goal, there should be a review at some point in time.

So here are the books I actually read in 2014, in the order I read them:

Non-Fiction

“Notes to a Software Teamlead” by Roy Osherove

Actually I listened to the audio-book, which was a great way to experience it.

Looking back though, I couldn’t really get much out of it. It’s a good book but apart from knowing about and sometimes working with the model of teams going through three phases, nothing more really stood out.

“Release It!” by Michael Nygard

This book, in contrast, totally blew my mind. Not only is it filled with so much great knowledge and patterns, it’s also a joy to read.

I would go as far and say this is a must-read for every developer who actually wants to see their code run in production, and should be used as a textbook to teach students the basics of operations.

“Ship It!” by Jared Richardson & William Gwaltney

“Ship It!” is a very concise and good read. It describes several very pragmatic practices on how to lead software projects. Even though that sounds like project management, the book is not in the least about project management. It’s more like a good friend’s advice on how one might make software projects sucessful.

“Art of Capacity Planning” by John Allspaw

That I admire John Allspaw isn’t a secret anymore. This book reinforces my opinion about him. Even though I couldn’t directly apply the main part of what the book is about, it’s a nice read and contains a lot of foundational knowledge about modern operations of software products.

“CQRS, The Example” by Mark Nijhof

This book contains a quick and easy introduction to a very specific CQRS implementation based on Event-Sourcing. It’s the basis of the first implementation of the vaamo codebase.

Recommended as an entry-level text into CQRS and Event Sourcing.

“Remote - Office not required” by Jason Fried & DHH

I expected not much, when starting this book. After all, DHH’s writing style and opinion is … let’s say, well known.

In the beginning there was no surprise. Without actually checking it, the first half of the book seemed to be excerpts of Signal-vs-Noise blog posts about the topic. The second half wasn’t a mindblow either but at least contained some new stabs at the topic.

Either way, if you’ve been living under a rock in the last years, then this book is a nice intro into the topic of remote work.

“Leading Snowflakes” by Oren Ellenbogen

This book was among the most influential for me in 2014. Oren, who also curates the much recommended Software Lead Weekly newsletter, has put together a super-concise and at the same time ultra-helpful list of concrete advices, that you can put to action almost immediately after reading. At the same time I’ve re-read so many passages of the book already, and will probably continue to do so.

It really is a must-have for everybody who even remotely considers themselves in a leadership position or simply wants to understand what leadership can mean in the software industry.
And with leadership I obviously don’t mean management.

“Hard Things about Hard Things” by Ben Horowitz

I like Ben. He is partner at a venture firm (vc, vc fund, or whatever the correct term for that is) with a controversial partner, but who wants to judge other’s life choices.

Ben’s writing is always clear and to the point. The stories he sprinkles into his advice are usually captivating and help illustrate his points. This book is no exception and even though it contains quite some older blog content of his, it’s still or even more so an incredibly easy and at the same time useful read on management and leadership. What I found remarkable is that even though Ben clearly addresses CEOs as readers throughout the book, a lot if not all of the points he makes are applicable to non-CEO managers and leaders alike.

Go read it!

“Managing Humans” by Micheal Lopp

Sometime in 2014 I stumbled across several mentions of “Managing Humans” and enough time had passed (omg, is it six years already?!) since my last read and I thought should reread it. I did this over several midday breaks on several weekends, so I didn’t actually read the whole book but only the parts that were the most interesting to me at that point.

It’s a good book, that contains some solid advice. But even though Michael is an outstanding writer I found the advice buried under too many story details. Additionally a lot of advice seems only applicable to very special situations that you and your team have to be in in order to really make use of them.

“Sketchnote Book” by Mike Rohde

This is one of those gems where you think, “how did I not think of this myself and earlier?”.

If you’re thinking about how you can take more useful notes, be it during meetings or whirl listening to a conference talk, then go read it. Or even if you’re just thinking about how you can visualize better.

It’s a tremendously well structured and beautifully designed book, which could be read in one go, but will linger on your mind for so much longer.

Bonus points for giving me the best excuse ever to take a stab at my “conference & ted talks to watch” list.

“Ich will wissen was du wirklich brauchst” by Frank Gaschler & Gundi Gaschler

Sorry, for that german content here, but this book is one of the three books in 2014 that instantly made it onto my “left an outstanding and long-lasting impression”-list.

It’s about applying the non-violent communication principles in your family, especially in the relationship with your children, and really helped me understand and handle a lot of situations in our daily family life.

“The Will to Change - Men, Masculinity & Love” by Bell Hooks

This one is the third book on my already mentioned “left an outstanding impression”-list. Even though I haven’t finished it yet, it already made me aware of so many problematic things and circumstances in my daily life. Not the least important of them the realization that we really do live in a patriarchy.
Reading this book in conjunction with having kids in kindergarten age, it’s extra remarkable how much of our culture and society revolves around dominating others by way of some kind of violence. Isn’t it striking that many if not all three year olds already know how firearms are supposed to work?

In any case, this is a must-read for anybody who is wondering what this feminism-thing is and what role men can have in it.

“Causation: A Very Short Introduction” by Stephen Mumford and Rani Lill Anjum

Another book I haven’t finished completely yet, but still think is a great book and that I learned quite a bit from it already.

At times a bit theoretical, big surprise I know, yet it manages to take you on an intriguing ride through the answers philosophers of past and present had on the questions of cause and effect.

Fiction

“Fuzzy Nation” by John Scalzi
“Redshirts” by John Scalzi
“Kill Decision” by Daniel Suarez
“Daemon” & “Freedom (TM)” by Daniel Suarez
“China Mountain Zhang” by Maureen F. McHugh
“Influx” by Daniel Suarez
“Lock In” by John Scalzi

As you can see I read quite some fiction novels. I especially liked Daniel Suarez’ books and also enjoyed “China Mountain Zhang” quite a bit because it was really different from the other ’standard’ as Sci-Fi novels. But I basically enjoyed all of them. Which may be related to the fact, that are all from only a small set of authors.

Unfinished Books

I have a bad habit of reading a lot of books in parallel, and sometimes pausing a bit longer on some of them. I plan to get back to most of them at some point.

“Thinking in Systems: A Primer” by Donnella Meadows
“Becoming a Better Programmer” by Pete Goodcliffe
“Thinking with Data” by Max Shron
“Data Science at the Command Line” by Jeroen Janssens
“Pragmatic Thinking & Learning” by Andy Hunt

But I also have the good habit of not finishing books that I don’t deem worthwhile. Which is not necessarily a judgement on their quality but often simply means, that they are not interesting or important enough for me right now.

“The Forever War” by Joe Halderman
“In Search Of Certainty - The Science of Our Information Infrastructure” by Mark Burgess

Give me more

I’m quite some reading nerd, with a wide range of interests. If anything in the above lists makes you think I might like a certain book (or books), I’d love for you to tell me on twitter about it.

squeakyvessel

My new site: cto.coffee

Sonic Pi Workshop in Frankfurt

Workshop

Details

You need to bring

Register

My New Chapter, My New Role

My New Role

My Last Weeks

Why Crispy Mountain?

I'm looking for a new opportunity

Table of Contents

What’s next?

What I’m good at

Technology

People

What’s important to me

People

Freedom to choose time & place to work

Diversity

What I would love to do

Building Teams

Tech Evangelism, Developer Relations

Hire me

Engineering Ladders Linklist

Ladders

Missing a ladder?

Farewell Leader's Digest

On the Structure of One on Ones

Table of Contents

Structure

Prepare - Choose a Theme

Listen

Status Update

Conclude with Something Actionable

Dream Big

Hot Topic: How long is a 1on1?

TL;DR

On the Purpose of One on Ones

Purpose

Build a relationship

Provide a safe space

Long-term Goals and Career Development

Continuous Improvement

Give Feedback

Structure

Mature Developers

What Defines a Mature Developer?

Mindfulness

Curiousity

Pragmatism

Pro-Activeness

Having and Sharing a Technical Vision

Understanding Business Value

Reasonable Risk-taking & Decisiveness

Empathy

Excellent Communicator

Other Opinions

Reading in 2014

Non-Fiction

“Notes to a Software Teamlead” by Roy Osherove

“Release It!” by Michael Nygard

“Ship It!” by Jared Richardson & William Gwaltney

“Art of Capacity Planning” by John Allspaw

“CQRS, The Example” by Mark Nijhof

“Remote - Office not required” by Jason Fried & DHH

“Leading Snowflakes” by Oren Ellenbogen

“Hard Things about Hard Things” by Ben Horowitz

“Managing Humans” by Micheal Lopp

“Sketchnote Book” by Mike Rohde

“Ich will wissen was du wirklich brauchst” by Frank Gaschler & Gundi Gaschler

“The Will to Change - Men, Masculinity & Love” by Bell Hooks

“Causation: A Very Short Introduction” by Stephen Mumford and Rani Lill Anjum

Fiction

Unfinished Books

Give me more