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!
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.
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!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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!