Internal Projects: Working Inside the Panopticon
Developing and releasing internal projects within an organization is something most developers do when they join the corporate world. Usually, the aim of an internal project is to introduce a new service or workflow.
I’ve worked on frontends to help colleagues consume internal cloud services, which, of course, was the Trojan horse for (what was then) the private cloud. All significant projects, and some less significant ones, suffer from competing tensions because whatever their intended benefits, they cost resources and inevitably force some people to change their way of working.
A bad experience often scars developers, who blame this solely on corporate culture. Better to think about your organization as a vaguely beneficial Panopticon. Your management has sight of everything, but not at the same time. You can see evidence of management, although you can’t really perceive the details of how it operates. You have much less sight of neighboring teams and workflows, and they of you. People communicate through a set of predetermined pipelines.
The Panopticon was a design for an institutional building with an in-built system of control, originated by the English philosopher and social theorist Jeremy Bentham in the 18th century. When implemented as a prison, it allowed all inmates to be observed by a single corrections officer without the inmates knowing whether or not they were being watched.
Bentham expected that this “new mode of obtaining power of mind over mind, in a quantity hitherto without example” would keep the inmates in check. This form of fear-driven hierarchy still works in most large corporations effectively today. Of course, now it is multilayered, with every manager also being observed in the same way. We have become quite comfortable working with this balance of fear, which also keeps others in check.
The subject of running internal projects was covered nicely in a recent QCon London talk by Fabian Deshayes, who built an internal experimentation workflow with his team at Monzo.
One thing I liked was his reference to “products” not “projects,” where possible. Clearly, a project may create a product, but by focusing on the endpoint (i.e. end product) you give your team a forward focus and a smaller attack surface. You can also “relaunch” a product if things do run aground. I’ll stick with the term “product” in this post, and touch on stages of the development journey.
Now at some point, the term “developer experience” or DevEx gained ground. This can look good from the Panopticon, as it prompts a narrative of increased developer efficiency when observed from management, or “developer joy” when target users are being enticed to get onboard. So it is a beneficial viewpoint to maintain, but it requires work to keep the all-seeing eye focusing on the end benefits.
Building a Team
As well as the agile developers who can iterate quickly, the team for your internal project should have a number of reasonably tenured employees who have grown their own networks.
Personal networks are a very good way of influencing resources without depending on the Panopticon’s piped channels. You will also need soft skills from the developers to represent the product as it moves outwards from production.
Finicky developers who cause a fuss can get noticed in the wrong way, and are much harder to accommodate when the fast development stage moves to the communication stage.
Build Quickly, Respond Rapidly
Building quickly is important because your team is a resource sink, and that doesn’t look good over time. For this reason, you need to have lots of agile milestones, which can adjust to incorporate desired features.
Keep your user interfaces clean but familiar. Internal products are the wrong place to introduce entirely novel user experience (UX) journeys, except when making vital transitions.
So make sure your team is comfortable with integrating existing frontend designs — even when they are unfashionable. It is only important to appear to work within existing culture. Under the covers, where the Panopticon cannot see clearly, use what you need.
Here Come the Champions
The purpose of champions, who can advocate internally for your work, is to prove that your project is valuable from different parts of the Panopticon. The same observation method that can put down a counter-revolution can also observe the organic spread of a beneficial product. You need to spend serious time making sure that is what gets seen.
As a games developer, I’m used to having many concentric trust circles of people to show my unfinished work. This is slightly harder in an organization if you haven’t spent time building a network. But with patience, you should find the right people to both use and praise what you are delivering.
Communicating Your Product’s Strengths
Being able to create a multi-layer narrative might sound like marketing-speak (because it is). But that is the key to pushing an internal product and keeping it afloat.
Just as there will be champions, there will inevitably be others whose KPI would seem to involve shutting internal projects down. You need an elevator pitch to describe your product, but you also need other lines that target the audience.
If your team is regularly referred to as a “cost center,” for example, you may have started communicating too late. You may need to say how it empowers users, saves cash or fits into your organization’s future direction.
Your pitch depends on which part of the Panopticon is looking your way. Some people want their differences underlined, and conversely, some want differences in the organization squashed — hence the need for a flexible branching narrative.
You can also work indirectly with things like a Community of Practice to help co-locate users’ problems with your product’s solution.
Onboarding: Start Where the Users Are
The meeting place for developers or users will probably be Slack or even a Confluence page. But wherever the culture dictates that your users should gather, be there. Make sure your project team has access to it, which means, in Slack’s case, also having permission to use bots. You need to showcase your product in the places where your users discuss their work.
Make onboarding simple — but make sure you take names. Understanding how to identify people is usually simple within an organization, where people might literally have an identity number. Booking systems via a “portal” might have the advantage of including identity. Understanding how to transmit responsibility without appearing onerous is an art form that many apps have tried to get right.
The onboarding workflow is also part of your performance metrics, and you need to nudge people along. I would expect you start with a signup, then adoption, then a cleanup period. You will also want to shoehorn feedback in there, too. You’ve no doubt experienced this workflow every time you’ve signed up for an app on your phone, so make sure you can emulate it.
Of course, measurement and feedback can help prove your project is effective, as well as prove that the team working on it is effective. You need to think about feedback as you design the product, so that the Panopticon does not control how you are perceived.
Take Care When Selling an Internal Efficiency
It is perfectly reasonable to fold a few disparate systems into one system, then leverage the cost savings. But this benefit is largely a win for the purse holder for that area. It is unlikely to be interesting for the average developer to say “please use this entirely different system, it saves my department budget.” While no one will openly disagree (because the Panopticon is watching), you will be held in scorn.
In nearly all cases when you optimize in this way, you will also introduce improvements. Your job is to introduce these improvements to users as quickly as possible, while also eventually reaping the rewards from the efficiencies.
Your users will eventually be your champions. This is the way of the Panopticon: think of the different interests observing you simultaneously.
Nudge, Nudge
Remember that when you easily start cloud resources, you’ll have to remind people to shut them down afterward. Cleanup is one problem that appears to come last but gives out a dirty exhaust that can be seen from the Panopticon. What are all these clearly unused compute resources doing? Who is responsible here?
Just like feedback emails or Slack requests, set up a bot early on that can contact users when any part of the workflow looks stale. Yes, this means unused cloud compute, but also unfinished registration, etc. It is a dynamic part of the workflow that keeps your system moving and your targets on track.
Conclusion
At some point, you will have to win the victory over yourself and learn to at least respect the Panopticon. Of course, I’m using this as a slightly ugly metaphor for understanding the different perspectives that always exist in an organization but don’t necessarily support your interests.
To give the best chance of success for an internal product, you certainly need to navigate these. If you do as much as you can to work on all the stages before you reach them, you are less likely to be hijacked by events. Just remember to always have the right narrative for your audience as the product develops. Someone is always watching.
