Hello,
This week someone asked me a simple question. “Who should create that ticket?” It’s probably a question that’s been asked many times before. Who creates tickets? Who updates your issue tracking software? Who writes test cases? Who sends release notifications? There’s endless questions to ask about who does what.
But I realised something. The answers to those questions should be obvious. There shouldn’t be the slightest ambiguity or doubt about which people do what work, because as soon as there is doubt there are questions, and once there are questions there are delays.
So, can everyone on your team answer those questions without a further thought? I’d be willing to bet that they can’t.
I think almost every software team I’ve worked in has at some point gone through a phase of documenting how they work, in an effort to avoid such questions being necessary. Often the trigger for this is a round of new hires. New people need to know how we operate, so we’d better write it down. Almost without fail this results in the first new-hire getting the job of documenting how a team works. On occasion I’ve been that new-hire, and let me tell you, it’s a horrible way to join a team.
The whole reason we want to write this stuff down is because it’s hard for new people to assimilate the information. It’s awkward for them to ask questions about everything and there’s every chance they’ll miss something important because they didn’t want to bother the more experienced team members. So getting the new person to document your process is an absolute non-starter.
Furthermore, I’m pretty certain that if you asked each existing team member to document your process they’d all come up with something slightly different.
So, what I would do in this situation is exactly what I do when I’m starting to help a new team to go faster. I get them all in a room and I ask them how a feature goes from idea to live-in-front-of-customers. We draw a diagram on a whiteboard, or we arrange post-its on the wall. This can take a surprisingly long time. People disagree on seemingly fundamental points (“Do we do QA after we merge, or before?” “We use git-flow.” “Well I don’t!” etc). Take the time and build a consensus representing what the team actually does, not what they’d like to do or think they should do.
Once you have it documented, turn it into a nice big diagram and stick it on the wall. That’s right, on the wall. Not buried away in some wiki somewhere, not on the shared drive, not anywhere electronic. On the wall. Wikis are where documentation goes to die. The wall is where it thrives.
That way, when a new person starts you can show them how you work in just the same way as you show them to their desk or show them where to get a cup of tea. Nobody needs to be in any doubt, and the constant presence of the big diagram on the wall means that people remember what they agreed to.
You might occasionally need to re-draw bits of it, of course, but that’s just fine as long as everyone still agrees on the process you’re using.
Hopefully you’ll find that you spend less time answering questions are more time delivering software to your customers.
Going Faster: Weekly ideas on speeding up your software team by Jez Halford, a software development consultant helping teams to deliver better software more quickly. Subscribe at tinyletter.com/goingfaster to get Going Faster in your inbox.
There’s more from Jez on Twitterand jezhalford.com
Top comments (3)
Jez, I love this post and wanted to share a few thoughts that might spark a broader discussion...
Having been in engineering, ops, management & consulting roles at a variety of companies I can say with total confidence that the problems you describe as the source of inspiration for this post have existed in some form or another in every company I've worked at or with.
In my experience I've seen the same types of issues (at least at some point) in a startup with just a few cofounders almost as often as I'd see it at firms with 100k plus headcount.
My original sense of how to solve the problem echoed your own suggestion here - our people are the real asset to any organization so get the key people in a room and write this stuff down! And just like you describe here, it solved that immediate problem of on-boarding that group of new hires who just arrived and we all got back to work solving problems for our company and our clients...
Of course, if we were successful at doing our jobs, in almost no time at all we were growing the team again and we were right back where we started...why? Based on what I have seen, the problem with our use of this approach boiled down to a few core issues we needed to address at deeper level:
First, There's an big assumption baked into both this "post it to the wall" approach and the statement "wiki's are where documentation goes to die.." that's fundamentally at odds with how every successful software team I've worked with and how every one I've ever read about actually operates...they're staffed by incredibly smart people who are given enough freedom to use their creativity and ingenuity to solve problems as they arise how THEY best see fit.
They are expected to start with some shared knowledge the team has acquired and then adapt and change as they acquire new knowledge and as the technology we work with evolves over time. Putting a static document on the wall definitely helps discoverability, but it's a STATIC document and that's not at all how any successful team works. Ideally, as every problem is solved the team works whatever innovations were leveraged back into the collective team system and that means updating that diagram in a continuous learning process.
Even worse, one of my new hires mentioned something to me in our first regular 1 on 1 and told me that she was worried she might have made a huge mistake in accepting the role...her first thought when seeing that static map was that we didn't really value her ability to create innovative solutions to problems we were solving...we wanted her to repeat some static process over and over again based on what others thought was best...like a robot
:|
A huge part of our interviewing process was based around specifically engaging our engineering and ops team hires in problem solving challenges that weren't specifically language-or-platform based but focused on how they approached deconstructing the situations presented and how they asked questions about the problem and how/if they asked questions about other teams that might be involved if they had the chance to reach out to them.
Lastly, There's a more insidious (though probably lesser in immediate effect) problem embedded into the statement about wiki's being the place where documentation goes to die...although I'd have agreed that the statement was pretty much an accurate description of nearly every firm I'd either worked for or with at some point...it masks a more fundamental problem - namely that that can ONLY be true if the business does not make the process of using, capturing, and updating knowledge a fundamental part of every employee's jobs.
And the saddest part of that is that at our core - we're not programmers or pm's or managers or accountants or whatever our job titles say...(at least in my experience) if we're GOOD / GREAT at what we do, we're first and foremost problem solvers. Sure we might use code or jira tickets or gantt charts or spreadsheets or (pick a tool here...) whatever to solve problems at a point in time, but as every employee progresses and the business grows the one thing I've noted that is common across every employee is that this changes.
At some point at one of my earlier roles, a few other people who were amazing problem solvers started discussing how to attack this deeper issue...fortunately is was a few people who spanned roles across Ops, Engineering, and included a few Managers and Senior Management types with money to contribute as well as smarts and we discovered that there's been an organization that has been working on the deeper problems for a couple of decades now and it's mostly comprised of smart people from a wide range of tech (mostly tech in the early days) but importantly MANY non-tech businesses across nearly every sector in our economy...
The group's called The Consortium for Service Innovation and their initial innovation that has been refined over the last few decades was the Knowledge Centered Service process. It's pretty well explained on their site, but the one thing that stood out in that first that first team I'd stumbled into was that in every single study that had ever been documented one thing was overwhelming the same (despite a lot of other variations)...until the highest executive at a firm made a commitment to making the process of using, capturing, and improving knowledge a fundamental part of every employee's role, they experienced the same problem of getting a short term improvement then the regressed back to the mean when they grew.
In our specific case, and as it turns out in every documented case study we could find, this required much more than just writing some mission statement. Our exec, and everyone down his org chart modified their performance plans to voluntarily put our money where our mouths were...it took us a while to work through the process and make sure we tweaked it to our team / org / company's needs, but the impact was literally astounding. It so transformed our org that our exec became CIO, our internal customers began asking how IT, Eng, Ops made such a change in such a short time and then began adopting this process to their non-IT service delivery frameworks until almost 45k of the 75k employees in the entire company used this process every day to ensure that entire organizations of the firm made this usage, capture, updating and NOW sharing of knowledge as central to their daily work as checking email.
It was transformative for me and my team personally...we managed to literally double the number of products our factories were able to ship by starting with our Factory Automation Ops team that I led, then bringing our engineering and dev teams into it and in 9 months generated nearly a billion dollars in additional revenue and profit and changed the financial future of one of the 25 largest companies in the world...not that we planned any of that or could have predicted that would happen when our team got together for a beer or two and a chat one day...
At any rate, I thought I'd share this since your post reminded me of similar conversations I'd had with my teams I led or my own leadership over and over again that just never seemed to get solved at scale as we grew until we did something fundamentally simple but somehow overlooked by so many (including ourselves for most of our careers). Hope it sparks a little discussion about short-vs-long term challenges and the struggles of dealing with local min-max views when solving problems at organizations of all sizes!
Hey Bryan,
Thanks for the lengthy response! I'll have a dig into the Consortium's work, it seems fascinating.
I think your calling out of the distinction between short and long term strategies is a great point. My "get everyone in a room and stick it on the wall" approach is very much a short term remedial strategy. It's basically what a paramedic does versus what a doctor does, and I appreciate I didn't really make that distinction in the article.
Long term growth and success is a very different problem, and what you describe sounds like a great way to go about it. I'll be sure to do some reading on the subject.
Thanks again.
Jez
Excellent point re: Paramedic vs. Surgeon Distinction.
Based on my own experiences, I would be sure to keep that in front of mind because those "stop-gap" measures have a nasty tendency of becoming standard processes by default when they're not explicitly focused on later for removal / modification. Great post and again, thanks for sharing it with the dev.to community!