In January this year Charity Majors wrote Engineering Management: The Pendulum or the Ladder as a follow up to The Engineer/Manager Pendulum. It’s a great article with a realist lens on the career paths of software engineers going into management. It’s obviously a position built out of real world experience and provides a viable career template if you want to keep your technical and leadership skills in balance. It’s damned fine advice and it works.
Last month I ran the first conference booth (cough, conference cocktail table) and I just wanted to share a few bits and pieces from the experience in the hope it’s helpful for other early stage founders to do the same.
Doing a booth at this stage of the company’s life wasn’t really on my roadmap, but the very kind John Allsopp emailed me out of the blue with an offer I couldn’t refuse — to be part of the Web Directions Summit devtools showcase.
I also mooched some free accommodation from the Buildkite team, staying in a kind of creepy…
In the classic management book High Output Management Andy Grove argues that “training is the manager’s job” because it’s the highest leverage activity a manager can do to increase the output of their organisation.
It’s still great advice for managers applicable across most teams, but for the manager of the modern software development team the fulcrum point has shifted.
The code review, usually performed using GitHub pull requests or the like, is now the highest leverage point for improving an engineering team’s output.
If you’re writing an all time top five list of controversial engineering management topics, I can almost guarantee that the question of whether managers should be coding will find a place on the list. I’m very firmly in the camp of managers who do, and believe they should, code but it’s entirely understandable why so many people come down on the other side of the issue.
According to a recent study published by Harvard Business School, employees are happier when managed by someone who can do their job. To borrow from an old NASA engineer’s rules “Capabilities drive requirements, regardless…
I just wanted to write a quick post to introduce my new startup Hecate and explain what it’s all about.
For those who don’t know me; Hi, I’m John. Until recently I was the head of engineering at 99designs, and before that I was leading the Marketplaces Engineering team at Envato, responsible for (among other things) their flagship product ThemeForest. One big contributing factor to those teams’ successes was a strong culture of Continuous Delivery and having the toolbox of techniques and practices to support it.
Over the past few years Continuous Delivery has become a mainstream practice and a…
Happy 10th Birthday Github Pull Requests! Introduced on February 23rd 2008 in their 3rd blog post.
My guess is that in discovering PRs are 10 years old you’re having one of two reactions.
My reaction was definitely the first one. I’d stumbled across the introduction post while I was researching the history of code review, which in turn was prompted by the Go community’s discussion regarding Gerrit vs Github.
It’s amazing to think about how over…
Over the past few days Charity Majors has been at the centre of a wide ranging twitter debate around whether developers should go on call. Her position, which I agree with 100%, is that developers should.
Because it’s a conversation that’s gone on many tangents, it’s hard to pick a single twitter thread that’s representative. This one in the middle is pretty good.
I can completely empathise with why discussing on call can be challenging. Charity herself mentions that a lot of people have PTSD from bad on call experiences. …
Today I finally finished reading One Strategy: Organisation, Planning, and Decision Making by Steven Sinofsky and Marco Iansiti. I checked my email to see when I started reading it. Amazon tells me it was delivered on or around December 21st 2016. It’s very rare for me to spend just over a year reading a book. I usually finish them quickly or abandon them, but I pushed through on this one.
If you’re an engineering or product manager this book is a must read. Format wise the book is a bunch of internal blog posts Steven Sinofsky wrote at Microsoft in…
As far as I can tell there are roughly three flavours of working style in an “agile” environment that all get named “iterating”.
Let’s call the three flavours scientific, greedy, and defensive. There’s definitely some overlap between the three. I want to explore them a little in this post a lot of the interesting (BYO airquotes) moments in engineering management come up when the different varieties rub up against each other.
For the sake of this argument these are the definitions I’m going to use.
Seems like you can’t swing a cat without hitting someone’s year in review blog post. The world won’t have been screaming out for me to add to the pile, but I wanted to pick something pretty quick and easy to smash out today. Primarily to put the new blogging part of my new site through its paces, but also to try and jump start the habit of writing more frequently.
Bicycle, book, and booze enthusiast. Rubyist and Gopher. Founder @HecateApp, ex @99designs/@envato