I’ve spent the last year as a software engineering manager for teams building a new product. Our tribe (the group of teams) is part of a larger organisation. Here are 14 things I learned:

  1. As an engineering manager, you have only one goal: create a space where people can make good software, all the time. Everything else you do should be subservient to this goal. Everything that doesn’t contribute to this goal is a distraction. As one of the principles of the Agile Manifesto puts it: “Build projects around motivated individuals. …


Image for post
Image for post
Photo from News24

I often see situations like this in software teams:

Alice: “We can’t begin testing because we’re still waiting to hear from Bob about when the RC will be ready. He will let us all know in the official Slack channel. Stand by.”
Bob: “I know you’re all waiting for the RC but I need confirmation from Craig first, and he’s not responding to his email”.
Craig: “Usually it’s Dan who makes this decision but he’s on holiday and he didn’t brief me on this when he handed his tasks over to me…”.

Typically, I (mis)diagnose this as a problem of ignorance. The roles and responsibilities are not clear enough! Let’s make another checklist, create another role, set another OKR. This will help people to understand exactly when they’re right or wrong. …


Image for post
Image for post
Tools image via Shutterstock

I recently read an article about how scrum disempowers developers due to its focus on value rather than technical excellence. This is something that resonates with me, so to “pump” my intuition I want to do a little thought experiment where we try to stay within the scrum universe, but try to solve the main problem (developers being disempowered by scrum) by modifying the scrum framework.

As the author of the article states, “Scrum has a master, product has an owner, but no-one is empowered to advocate for development priorities.” To remedy this, let’s add a new role to scrum called the craft master. The craft master guides the team to understand their work as a craft, and to help them reflect and improve on it. This person does not necessarily have to be an individual contributor (much like the scrum master). The craft master has excellent technical leadership skills, deep technical knowledge and keeps abreast of what’s happening in the world of “software craftsmanship”. The craft master makes sure that the team’s notion of quality and craftsmanship manifest in the Definition of Done, and brings the Definition of Done to the foreground as an integral part of scrum. …


Something I realised recently (which I knew in theory but ignored in practice) is that reminding teams that they are the ones responsible for quality (through incrementally developing their Definition of Done) is crucial.

Entropy is inevitable. Technical debt will accumulate as time goes along. At some point, technical debt becomes so much that teams will want to add “technical stories” to sprints. People start arguing that senior engineers should have equal footing with Product Owners about what goes into the backlog. “We have so much technical debt — we need to treat it just like any other story and prioritise it into sprints!” the team would murmur. …


In April, Roland and I presented a workshop on systems thinking at the MiXiT conference in Lyon. Check out the presentation and case study we used. Also check out this list of systems thinking resources.

Image for post
Image for post


Me and two friends started Glio in September 2012. By day Glio was a consultancy, offering website development (mainly with WordPress on LAMP) and graphic design services. By night Glio tried to be an incubator — we hashed out hypotheses and ran lean experiments, but unfortunately nothing sustainable ever emerged from these endeavours.

We finally shut Glio down sometime at the end of 2014. It goes without saying that I learnt loads during these two years. This post attempts to chronicle these learnings.

  • You’re in for the long haul. Despite what Silicon Valley might make you think, building a company is going take time. At times, it’s going to be boring and unglamorous. It’s definitely going to be hard work. Make sure that you realise the gravity of this, and make doubly sure that your partners realise it. …

Many software projects take on the form of a transaction between vendor and customer. A transaction is an exchange of value. The vendor supplies software to the customer that solves some problem (scope), costs a certain amount (budget), by some date (schedule). The customer (hopefully) pays the vendor.

In any exchange of value, there exists the possibility of an unfair exchange. That is the situation where one party gains more value out of the transaction than the other for some reason. This possibility of unfairness is the risk associated to the transaction.

Typical contractual agreements between vendor and customer distributes risk in a certain way. …


There is a certain narrative that is prevalent in contemporary startup cultures. Its story goes something along the lines of “failure is good so long as you’re learning from it”. On the surface it suggests speed and adaptiveness: fast-moving iterations driven by a tight feedback loop calibrated to avoid waste (who wants to spend hours building something nobody wants, right?). I’ll be the first to admit: it sounded smart, tenacious and brave.

But this version of failure has a subtle consequence: stagnancy. All of a sudden the act of failing becomes a mundane event, just one of many more to come. Failure loses its power. It strips you of the ability to question the bigger picture. …


I’ve recently learned a lot about Ruby, and I’m also quite interested in R, a programming language for statistical computing. The book Exploring Everyday Things with R and Ruby naturally piqued my interest.

Overview of the book

The first two chapters does a quick primer on Ruby and R respectively, and does a sufficient job to get you up and running with both Ruby and R.

The remaining six chapters each tries to “explore” a question. …

About

Emile Silvis

I help awesome people create the banking platform of the future at http://www.backbase.com . Views here are my own.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store