Why is it that many bands hit a high water mark on their debut album that they never again live up to? Why are some bands able to reinvent themselves album after album and continually achieve new heights? Why are some musicians able to juggle multiple bands and side projects, producing quality work across all of them?
While most of us are not under the same level of scrutiny as popular bands, our careers have similar challenges. The first days and weeks of a new job feel fresh, but research shows that a “hangover” sets in around the 6-month mark.
Since I’ve been on a running kick recently, I decided to add some variety to my runs and visit just about every bridge that crosses the three rivers with pedestrian access and a view of the city. I have no talent as a photographer, but thought it would be interesting to take one photo per bridge to see the city from a variety of angles.
Paul Graham’s 2009 essay Maker’s Schedule, Manager’s Schedule was a big influence on me as I was shifting from full-time software engineer to managing software projects (while also trying to find time to write code daily).
Just like schedules change drastically based on role, metrics undergo a similar shift.
A key principle of Agile is “self-organizing teams”, where the makers have a high degree of autonomy. Managers play an outward-facing role, acting as a conduit between teams and the organization while focusing on coaching, mentorship, process improvement, and removal of impediments.
In a previous post, I outlined important Agile metrics…
Is your team improving? How can you quantify the efforts of team and process improvements that have been put in place over time?
Some will be quick to say that shipping working software is really the only metric that matters. Others will be concerned that metrics have the potential to burden teams with red tape and minute details that don’t really matter.
With respect to both positions, there are ways to sensibly capture the activities that go into shipping software, specifically around cost, quality, and time. If a project was a huge success, we should be able to understand why…
Technology, science, and math have countless eponymous laws. In the world of software, three specific laws tend to crop up in just about every project and team: Parkinson’s Law, the Pareto Principle, and the Peter Principle. I’ll outline some ways to counteract each of these in future posts. First up…Parkinson’s Law (Law of Triviality).
Parkinson’s Law, coined by C. Northcote Parkinson states that “work expands so as to fill the time available for its completion”. …
In The Mythical Man-Month, Fred Brooks outlines The Second-System Effect, which “is the most dangerous system a man ever designs.” This post looks at first systems, second systems, and how the trappings of second systems can be avoided.
The goal of an engineering team at a startup is to get a functional software product built as quickly as possible. The product typically needs to be “just good enough” quality-wise, while fitting into a shoestring budget and tight deadlines.
Over time, more features are added and corners are inevitably cut, but it’s all done in the name of working quickly and…