Enjoy software development more with Uclusion
Stock options have long been tech’s secret sauce for keeping software developers engaged, but cap tables don’t solve all problems. In my previous startup founder shares were divided very unequally and that ended up sowing discord and preventing innovation.
In Uclusion, we started with a bootstrapped, two person 50 / 50 equity structure but even high equity is no guarantee. First someone may contribute more and over a prolonged period that will generate friction. Or there can be a divide in the roles that people perform.
Larry Page and Sergey Brin had Scott Hassan cut out and then Eric Schmidt cut in as chairman and CEO of Google after only three years. Even going back to Hewlett and Packard, Hewlett was drafted into World War II and Packard was not and Packard was president after incorporation and Hewlett was not.
Plus, traditional startup four year vesting in an environment where the average time to exit is eight years doesn’t make any sense except as part of a trend of lack of innovation in work structure.
Most companies can no longer give significant portions of cap table pie, but developer engagement can still be driven by an environment where people work with others not for them.
Beyond equity
Open source and Wikipedia can exist because people are willing to bend the normals rules of compensation when they buy in. Product managers spend a lot of time trying to get that buy in, but that can easily collapse into giving orders. A PM that has to give detailed orders is dead in the water in with the level of speed and complexity required to build today’s software.
Not micromanaging is the only way to avoid that kind of zombie software development and trust is the only way to not micromanage. Employees with greater ownership are trusted more than those that are not vesting valuable shares. So companies with employees doing well from stock options are flatter. Google has an average of one manager per twenty workers, compared to the American average ratio of 1:7 (depending on how you count). Nvidia is very flat compared to most tech companies its size.
But companies can choose to trust employees that aren’t stock endowed and reports that “flattening” might backfire misunderstand worker engagement.
When companies are removing managers, it makes the career path forward not quite as clear.
No flattening makes the career path more clear - keep contributing to be rewarded.
In 2023 any advantage in employee engagement can make a huge difference to the bottom line and hybrid work and flattening are just two ways to reduce micromanaging.
Scrum, Slack, Jira and products like them reduce engagement
Scrum encourages synchronous consensus building during time pressured meetings - frequently without advance preparation. The concept of a “sprint” was invented to fix organizations before Scrum that wanted to plan every detail of a project for months or years. But the original problem before Scrum was not detailed long term planning, it was forcing plans on developers without their input. Scrum ends up encouraging forcing plans in one to three week chunks, and even asking for up front, unchangeable, estimates on those chunks.
Similarly synchronous communication in Slack again needlessly increases a developers real time burden. Contrary to its name Slack makes everything urgent and difficult to process while doing complex work.
Finally, Jira and other “ticket” based solutions complete a three-legged micromanaging stool by positioning ambiguous, agile software development as straight forward tasks. Nor does just throwing a Kanban board on top of software built for bug tracking fix the problem.
Useful, self-directed work
Uclusion is built ground up around feedback. At first, we imagined that feedback would come primarily from customers but that’s just too slow. If you have to wait for customers to explain in detail how your product should work then you are in even worse shape then waiting for PM orders.
There is nothing wrong with customer feedback - it’s a question of how often you can afford to go to the well. If you ask the customer on every little point instead of using internal discussion first, you will surely burn out their help. It will also take too long as scheduling time with the customer isn’t easy.
Or sometimes you get a single point of contact for the customer that is available a lot but that single person is not as good as using your internal team for feedback as well. However you look at it squandering valuable input from the team coding the details of the business logic and presentation layer is bad.
So instead Uclusion allows a development team to give all kinds of feedback - on questions, on suggestions, in response to a high level review request, and certainty that a job is worth doing. Each kind of feedback is supported by a structured type (IE you create a question not a generic comment), built-in Uclusion workflow and an inbox notification that provides context and quick action buttons.
A PM or tech lead can create a job or bug and let the team flush it out and assign or vote or comment on jobs or bugs that others in the team create. Status on jobs is required, but it’s also self-directed as developers can change estimates or pause jobs for assistance.
Signing up starts a sandbox demo where you can be part of a team using Uclusion. Please see if it more matches the way you want to work.
