Having built software for other people for over 10 years, Stefan Kent has seen the good, the bad and the ugly when it comes to running software teams.
Recently tasked with building a Y Combinator startup as Head of Technology for Snappr, Stefan has come out the other side of his Bay Area experience with the realisation that the systems in place for managing software teams are broken and have been for some time now.
The Future of Software Management
“We need to start by taking a step back” – Stefan Kent
We need to allow for a little paradigm shift. To stop thinking of developers as just builders but rather creatives.
Stefan likens the process of creating software to that of writing a novel, rather than that of manufacturing a car (Scrum methodology is based on the Toyota production system).
They’re not reproducing an established design, they’re creating the design as they go.
However, with the move towards trimming the fat, removing any inefficiencies and creating processes software development has been turned into a business unit.
Moving away from its early basis of creative tinkerers/hackers that created the software industry in the 90’s software developers now need to be controlled and managed for maximum efficiency.
In particular, Stefan believes that the Scrum subsection of the Agile framework, for managing product development, is to blame.
Why Not Scrum?
So what’s the problem?
Why is it so unreasonable to let business interests find a way to monetise hacker’s excitement?
After all, having some business savvy and a viable product should feed back into the developer’s ability to continue to create.
Well, as Stefan puts it, a regimented approach to software management and development (such as the Scrum methodology) has had profoundly negative effects on the eventual quality of the product created.
According to Stefan Scrums shortcomings come in the form of:
- Violent transparency
- Business First
- Terminal juniority
Scrum breaks down software developers work beforehand into iterative pieces that are estimated, tracked and reported on.
It’s all about measuring whether a project is on track.
Performance is broadcasted daily which in Stefan’s opinion doesn’t allow time for creative ups and downs.
You’re either producing consistently every day or you’re not productive.
According to Stefan, Silicon Valley still leads by example because of its engineer-driven companies.
The biggest Valley companies to have popped up and stuck over the years were built by and in some cases still run by engineers.
Viaweb, Google, Microsoft, Facebook, Paypal.
They didn’t rise to dominance because they had a team of software developers executing an investors idea.
They had one or two hackers, working for almost nothing on their own terms, on their own time to build something that excited them.
The Scrum methodologies combination of constant monitoring, mixed with experience being pushed aside because of the business needs leads to a high turnover of senior developer roles.
Senior developers know what needs to be built and how to build it.
Forcing them to break their work into by-the-hour chunks, estimating on these chunks while being forced to justify their effort and the process of creating software before they build it only serves to prioritise the process over the product.
For these reasons, Scrum teams slowly lose their seniors as they move to smaller startups or become contractors. Leaving the junior and those who are more comfortable with the build by the numbers approach.
In Stefan’s experience, Architecture and R&D have no place within a two-week Scrum iteration and unfortunately, that’s what Seniors excel at.
The future of software development
So the question remains, what can be done?
Stefan doesn’t claim to have all the answers.
But he does suggest we go back to the basics.
See how software is built, ask the people doing the work how they can do their work better.
He believes if we hire the right people, they’ll go out of their way to tell us. Because they’re doing what they love.
Stefan’s main suggestions were as follows:
Hire the right people
“Find the hackers, not the salarymen”
Get out of the way
“Define the what, and let them handle the how”
Create an environment
“Music helps with focus; when you need a rhythm to get process work done.
Silence helps with creativity; novel ways of combining concepts come together when the mind isn’t distracted.”
Respect the Downtime
“Let them get away from the screen, the best ideas come in the shower”
Work on Trust
“None of what I’ve said will work if you don’t trust your devs or they don’t trust you”
Our take on the debate
We know this is going to be a divisive topic within the startup community that will almost certainly be divided along the lines of product managers vs senior developers.
At the end of the day maybe Scrum is a very apt term because it seems this methodology involves two opponents violently bashing their heads against each other.
When Stefan presented his position on the day we fully expected an audience member to either walk out or attempt to call him out.
Luckily this wasn’t the case and the following debate had over breakfast was some of the more challenging we have experienced at our events, which is what we want.
So our point of view is, it’s important to find some middle ground both parties can agree on.
The Product teams need to have an understanding and appreciation of what the engineering team envisions and is designing.
But, at the same time, the engineering team needs to appreciate what the product teams has to achieve to make their creation viable.
Hopefully, that doesn’t seem like a cop-out to you.