teams

A collection of 26 posts

organisations

Steak and Salami

Ever had the feeling you're working constantly and getting nowhere? Specifically, the one where you've got a dozen things to do and none of them are getting done? Did you find that the more you worked, the worse the problem seemed to get? This is something endemic to the modern,

agile

Servant Leader, Helicopter Parent

Why is developing software so slow now? Provocative statement, so let's unpick. Maybe I'm getting more impatient as I get older, but the pace of modern software development feels glacial. Honestly, why do simple app features or new API endpoints swallow half a team for three or four weeks at

teams

Interviewing by Teaching

I've been trialling a new technique in interviews recently, and the results so far have been good so it feels worth sharing. Essentially it's a refinement of the "try to make the interview as much like the real work environment as possible" approach I've written about previously [https://mattkimber.co.

teams

Mentoring, not hiring: The Reality

Semi-anonymous Internet idiots like me love telling you all these things you should be doing about team structure, organisational approach and Really Exciting Technology but we're often a bit light on what happens when you actually do these things, and your self organising consensus driven team hits the switch for

teams

How to really identify a 10x developer

The sudden trending of "hashtag 10x developer" worries me. It worries me because it's not really about 10x performance, at least most of the time I've seen it. Instead, it tends to bundle two often overlapping movements which are unrelated to performance.

organisations

The 10x Developer and You

I'm in the mood for sarcastic graphs. I think (I hope) that the idea of the "10x" developer is not an astonishingly new and radical one. People in the upper quartile of the profession are not proportionately better than those in the bottom quartile, they're orders of magnitude better. But

teams

Thoughts on Interviewing

I think I'm destined to always be an iconoclast when it comes to interviews. Not quite so much as the days when "let's ask programmers some questions about programming" was a controversial idea, but I still find that when I introduce people to the way I do things they're sceptical

teams

Thoughts on team leadership and metrics

I realise that in four or so years of this site I've never talked properly about team leadership, which is a bit of an omission given how much time I've devoted to organisational design and how closely the two are related. I'm going to split this across a few articles

development

How I Learned To Stop Worrying And Love The Uncertainty

Data/object anti-symmetry broke me. The reason for this breakage was established a year or two ago. I had the fortune to work with some very smart people, who were very good at software engineering. As someone who'd had to fight for every slight increment toward clean coding, testability or

organisations

Two Transformation Questions

What exactly is a transformation? Is it "go to the cloud" or "be Agile" or "containerise the things"? Despite the number of organisations which state those as their goals, I'd say it isn't. Those examples are merely means to an end. They're often a part of transformation, but they're not

teams

Performance Reviews

I had an interesting conversation last night about that old bugbear, the annual performance review. No matter how many well-meaning attempts have been made with SMART targets or peer review systems, every annual review I've had or given during my professional career has gone something like this: * Here are a

organisations

Bias for action and agility

What has linked all of the high-performing teams and organisations I've worked for or with? That title is a bit of a clue: it's a bias for action. What this means is they believe the way to solve a problem or to improve things is to do something. A team

teams

Bad Team Leads and Responsible Adults

Does a team need a team lead? I've been thinking quite a bit about flat team structures over the past couple of weeks. As is often the case, it's recruitment-driven. I'm going to be blunt here: I've been really disappointed by the prospective tech leads I've been interviewing. This is

career

What is a Technical Architect anyway?

I spent a fair chunk of my career being a technical architect, most of which I also spent dreading the inevitable, "so what do you do for a living?" question at parties. Mostly I settled on answering, "I don't know" and quietly sobbing in a corner, because at least that

organisations

Firefighting

Firefighting is one of the biggest and most common causes of lost productivity and morale in software development. It usually manifests as developers being pulled off their project to urgently fix something - the live site is spewing 500 errors, there's a button in the wrong place, or a senior

agile

Working with both physical and electronic progress boards

Yesterday in a retrospective one of my teams asked a question which is all too familiar: "Updating both a physical board and an electronic board to track our progress is a bit annoying - can we get rid of one of them?" So we had a bit of a discussion,

agile

Agile transformation: The Low

A few months into any company's journey towards agile development I often see a point which I call the Low. This is where you've brought in a few experts, and done a few of the things they've said... but nothing seems to have improved and now people are wandering round

organisations

Waste

What's the difference between a merely good Scrum organisation and a great one? The answer is waste. Waste in a Scrum context is loosely defined as any activity which does not result in something the customer uses. At its most obvious we're talking things like TPS reports and bikeshedding, but

agile

Avoiding nightmare releases

Something I've seen a lot of supposedly Agile teams fail with is releases at the end of a project. Everything up to that point ticks along nicely, but the final sprint is a monstrous combination of time extensions, shifting scope, last-minute changes and unexpected problems. I've seen all sorts of

teams

JFDI Deployment

One of the things which small and startup companies often do so much better than large, established ones is encapsulated in this four-letter acronym: JFDI. Just Fearlessly Do It. (You can exchange your own 'F' if you prefer). The reason you JFDI so much as a small company is because

development

Repeating yourself

I think all good developers are aware of the basic axiom of "don't repeat yourself" - avoiding writing similar code over and over by making the effort to design and refactor what you've got so it handles all of your use cases. Where we're not so good is being able

development

No (more) heroes

A good development team has no heroes. There are three common "heroic" feats in software development: * Hacking in features in a fraction of the time it should have taken. * Pulling all-night hacking sessions to get a delayed project out the door. * Fixing a hack that exploded in production and took

teams

Why startups are fun

Working for a good tech startup is fun. There's a lot of energy, a certain amount of chaos, a huge amount of work produced and a general atmosphere of people enjoying themselves at work. It's something a lot of companies struggle to hold on to as they grow, and it's

teams

Ownership: Technical Debt

Hands up who didn't see this one coming? Technical debt is one of those strangely taboo subjects in the development world. Everybody has it, but nobody wants to talk about it when it comes to sprint retrospective time. Which is strange, as one of the first things any group of

architecture

Ownership: Architecture

I talked yesterday about what happens when development teams lose ownership of the software requirements. In that, I mentioned that teams need to own their architecture and technology stack. Surely this is so self-evident it barely needs mentioning? Well, not quite. In fact, it's incredibly common for developers to be