Software Project Management: Skip Management, Do DevOps
Most smaller and larger organizations are stuffed with folks holding various forms of the title “project manager” or “business analyst”.
For starters: These jobs are essential for any company. Why? A project manager holds the strings of a project. If she’s good, things – aka projects – just happen. In case he flops, the project will end up in failure.
Yet, most organizations have an oversupply of project managers, doing too many futile things: Another report, a chart, lots of meetings, more E-Mail. Bottom line contribution: Small.
Given that most organizations are run by business people (as opposed to engineers), there is a tendency to hire like-minded people first. Often the outcome is an oversupply of project management folks. At the same time the number of engineers stays mostly the same (Focus, you know, on costs and headcount and all that…).
The result is an oversupply of project management resources compared to engineering resources. The consequence is often a lack of customer focus and internal politics.
At local.ch and here at Squirro we worked and work hard to avoid this situation. We basically never employed a project manager.
At local.ch we had for an engineering team of over 30 just one engineering director and no project management. The main task of the engineering director was to provide direction for the engineering team. This required only a minimal part of day-to-day project management.
How did we do it?
- We split the platform into several building blocks and assigned a team and team lead to each block.
- Each team was responsible for its own objectives, tasks and their timely execution.
- Each team was tasked to ensure that its individual plans would not collide with the plans of adjacent teams and their respective release plans.
- We met every Thursday to discuss progress
- We relied extensively on agile development methods
- We made each team also responsible for operating their own code. This implied that a team member in turn was not developing new code but operating the platform.
The results – with all shortcomings – were very dedicated teams. They rose to their responsibilities and started to own the issues. They took pride in getting things done quickly, efficiently and effectively without much management.
Here at Squirro we have yet a smaller engineering team (we’re hiring… http://squirro.com/jobs). We again go for the same approach. Harry is our engineering director. Again, his prime responsibility is to provide a clear direction to the engineering team. The challenges with such a small team are multifold. Next to progressing the platform, we need to operate our customers hosted in the cloud and provide support to customers, which have deployed Squirro on premise.
We figured that for a smaller team the following approach works best.
- The whole team fully understands priorities and how they align to the overall success of the company. Given an inevitable over-supply of Work That Needs DoingTM the biggest challenge is managing opportunity costs; every project or task the team chooses to work on incurs a cost of N other things that can’t be done right now. With a deep understanding of priorities, each team member can manage their personal workload down to the smallest task in a manner that contributes most to the company’s overall success.
- We maintain a 2-3 month “radar” on upcoming customer activities, documented visibly for all team members to see and updated on a weekly basis together with sales, eliminates the “surprise effect” that can come from new projects with tight deadlines and allows the team to manage its time and energy effectively.
- Pragmatism trumps process; we work on a 2-week planning cycle (a sprint) to stay organized and juggle our longer-term product roadmap with pressing topics from customers, sales and similar. But we are not “religious” about this process when circumstances demand it, be it short term operational needs or research projects which need longer periods or focus or a different team setup.
- The team makes time to dig into the “unknowns” before making commitments to customers and stakeholders. Donald Rumsfeld popularized the “Johari Window” in 2012, with his comment “There are known knowns….”. In a startup with big ambitions its too easy to make the mistake of over-promising and under-delivering, which in turn teams to failed projects and disappointed customers. A small investment of time, discussing upcoming projects and tasks with the aim of converting “unknowns” to “knowns” does to a lot to ensure what we commit to ends up getting done.
You’ve never saw us use the word DevOps in describing the roles here at Squirro, yet we have years ago started to work along these lines with one simple objective in mind: Create a more engaging engineering environment.
The basic recipe is a transparent split of building blocks and assigned responsibilities. Plus, maximum delegation of decision-making combined with a set a set of simple and commonly shared ground rules. And then get out of the way and let excellent people do their job.
Born out of necessity at the time, we stumbled over a decade ago across a better way to create complex software products.
Squirro
Squirro is a cognitive insights solution turning meaningless data into actionable insights. Deployed by the world’s leading banks, telecoms, and other commercial businesses, Squirro’s cognitive technology extracts more value and business-critical information from complex data environments to improve operational efficiency and increase revenues.
Dr. Dorian Selz
Husband, father, internet entrepreneur, founder, CEO, Squirro, Memonic, local.ch, Namics, rail aficionado, author, tbd…
Harry Fuecks
Head of engineering @squirro
PS: We’re hiring! http://squirro.com/jobs