What Startups Accidentally Teach Enterprises About Development

May 19

Written By Eloi Tay and James Eyring PhD

Startups create developmental density by default. Enterprises can build it by design.

Most organizations do not have a development problem because people are not working hard enough. They have a development problem because the work does not always create enough challenge, practice, feedback, and support to help people grow.

Formal leadership development matters. Courses, assessments, coaching, and frameworks can create useful insight. But the real debate should not be whether leadership programs matter. It should be about the job challenges leaders face and the actions and behaviors they repeatedly practice while doing the work.

This is why startup environments often appear to develop people faster. They create challenges and learning pressure by default. A leader must operate across products, customers, technology, hiring, cost, delivery, and incident response because there are not enough people to divide the work neatly. Startups create this learning pressure by default. Enterprises have to create it by design.

Real work is not automatically developmental

Experience by itself is not enough. Repeated practice matters, but people can practice the wrong behavior for years. A leader can become calmer under pressure, or simply better at hiding uncertainty. An engineering manager can become faster at escalation, or more dependent on escalation because it keeps working.

Some people have ten years of experience. Others have one year repeated ten times.

The difference is not effort. It is developmental density: concentration of meaningful challenge, repeated practice, feedback, and support inside real work. A quarter full of delivery updates, predictable meetings, and narrow task ownership may be busy. It may not develop much judgment.

A stronger development design starts with four ingredients. Insight helps the person understand what capability or behavior needs to change. Challenge gives them work that stretches that capability. Practice lets them try the behavior repeatedly in real situations. Support gives them feedback, coaching, tools, reflection, and organizational help while they work through it.

This is close to the logic behind experience-driven development. The Center for Creative Leadership argues that on-the-job learning becomes more powerful when organizations make experience intentional, select stretch assignments, staff projects for development as well as performance, and build support around the work. [2] Organisation Solutions expresses a related idea in the FAST framework: Focus, Act, Support, and Test. [3]

Hard work can build judgment and new skills. It can also build stamina without learning. Development depends on how the work is shaped.

Technology learns this way too

Technology teams already understand this pattern. A system improves when people observe failure modes, change constraints, test assumptions, and tighten feedback loops. Logs, incidents, customer behavior, release friction, migration risk, and operating cost all become signals.

Leader development works in a similar way. Assessments and competency models can create insight. Programs can provide language and tools. Coaching can help leaders notice patterns they might miss. The development becomes stronger when those insights are connected to real work where the leader must practice different behaviors and see what changes.

A development goal such as “improve strategic thinking” may be directionally useful. It becomes actionable when the leader knows what strategic thinking must look like in the job: which decisions they should frame, which trade-offs they should surface, which stakeholders they should influence, and what evidence will show that their behavior is changing.

That is where the parallel matters. Technology learning and leader learning both improve when the feedback loop is close to the system, the practice is repeated, and the support is strong enough to help people adjust.

Why startups often create developmental density by accident

Startups often have higher developmental density because leaders touch more of the system.

The same person may deal with customer support, deployment, pricing logic, architecture, security exceptions, hiring, vendor conversations, and roadmap trade-offs in the same month. A product promise becomes a schema migration. A shortcut in the API becomes a support burden. A sales commitment becomes a platform risk. The system shows itself as a system.

Research on startup employment has noted that startup employees often operate with fewer resources, broader responsibilities, and more varied tasks, even though startup employment is not automatically better on every career outcome. [4] For development, this breadth matters because it gives people more chances to practice across boundaries.

For engineers and technical managers, this can be powerful. It teaches that technology decisions are rarely only technology decisions. They are product decisions, customer decisions, cost decisions, risk decisions, and people decisions.

But scarcity is not a complete development system. Without insight and support, it can become exhaustion. Without reflection, it can teach poor habits: avoid process, skip documentation, rely on heroics, and treat planning as overhead.

The lesson is not to be more startup. The lesson is that startups often create developmental density through constraint. Mature organizations can create developmental density through intention.

Why developmental density drops in large systems

Large organizations have advantages startups do not. They have specialist mentors, deeper expertise, mature production systems, governance, scale, and more capacity to support development.

The challenge is that the same strengths can reduce whole-system exposure. One team owns platform. Another owns product. Another owns delivery. Security owns risk. Finance owns cost. Talent owns development. Everyone may be doing reasonable work, but the leader being developed may see only a narrow slice of the real problem.

That matters because many enterprise development goals require cross-boundary practice. Organizations may want leaders to make faster decisions, collaborate more effectively, work with customers, become more agile, manage costs, or champion change. The operating environment sometimes makes those behaviors hard to practice because decision rights, incentives, calendars, and information flow remain fragmented.

This is not a failure of intent. It is a design problem.

Great development creates an operating environment where the desired behavior can be practiced. If the goal is better cross-functional judgment, the assignment must include real cross-functional trade-offs. If the goal is strategic communication, the leader must practice framing choices for stakeholders who see different risks. If the goal is agility, the leader must have enough authority and feedback to change course when evidence changes.

Design works best as a partnership

The strongest development designs usually come from partnership.

HR, L&D, talent, and coaching partners can provide insight tools, assessment, feedback processes, coaching, reflection routines, and mechanisms for practice. Practitioners and business leaders can make the development real by connecting those tools to the work that challenges and tests the capability.

Take an engineering manager who needs to lead through ambiguity during a platform or billing migration. The leader might be told they should become more strategic, communicate more clearly, speak with customers, move faster, and manage cost. Those are useful signals, but they are not yet a developmental design.

A stronger plan would make the migration the learning vehicle. The development focus might be decision clarity and cross-functional influence. Before each steering meeting, the leader writes a one-page decision brief: context, options, risks, recommendation, rollback trigger, and unresolved assumptions.

Then the practice is made repeatable. A staff engineer pressure-tests the technical logic. A product leader pressure-tests customer impact. A finance or operations partner pressure-tests cost and timing. The leader uses the feedback to refine the next brief rather than treating the meeting as a one-off performance.

Then the support is designed. The leader gets a short weekly check-in with their own manager, a peer review of one difficult communication, and a sponsor who can help remove a real dependency blocker. The test is also explicit: are decisions moving with less rework, are stakeholders clearer on trade-offs, and is the team learning from incidents rather than hiding them?

That is not HR versus engineering. It is a partnership. One side helps create insight, support, and practice mechanisms. The other side brings the operating reality that makes the challenge meaningful.

A senior technology leader example

The same logic applies to senior technology leaders, including Directors who may move toward CTO-level work.

A useful assignment is not simply “be more strategic.” It might be a tour across platform, product, and delivery while the organization is scaling, upgrading an important platform, and keeping the current system running. The assignment creates developmental density because the leader has to practice across architecture, customer impact, delivery rhythm, cost, team anxiety, and executive communication.

The point is not that every Director needs the same path. The point is that the work should create insight, challenge, practice, and support around the next level of judgment. Without that design, the organization may be asking for broader leadership while giving the person only narrow work.

Getting the developmental benefit by design

Enterprises do not need to copy every startup operating condition to get the developmental benefit. They can design the benefit deliberately.

Development centers can help leaders gain insight through on-the-job strategic projects, feedback, assessment, and development planning. [5] Action learning projects can help by balancing a real business issue with explicit learning goals, reflection, feedback, coaching, and sponsor support. [6] Multi-month development journeys can connect assessment, peer learning, action learning, coaching, and live strategic projects. [7]

The common thread is not format. It is developmental density. The work should contain a real challenge, repeated practice, timely feedback, and enough support for the leader to improve while still delivering something that matters.

That makes project allocation a development lever. So are incident reviews, architecture boards, steering meetings, promotion discussions, manager one-to-ones, and talent marketplaces. The organization already has a curriculum. The question is whether that curriculum is designed deliberately.

The useful question is not “Should we train people more?” It is: “Is the work designed to teach the judgment we say we need?”

Notes and References

1. Organisation Solutions internal evidence brief. Experience Rich Development as an Evidence-Informed Development System. Private source supplied by the authors.

2. Center for Creative Leadership. “Develop Strong Leaders With On-the-Job Learning.” CCL, 2020. https://www.ccl.org/articles/leading-effectively-articles/develop-strong-leaders-with-on-the-job-learning/

3. Organisation Solutions. “Are You Ready to Go FASTer?” Organisation Solutions, 2025. https://organisationsolutions.com/articles/are-you-ready-to-go-faster

4. Sorenson, Olav, Michael S. Dahl, Rodrigo Canales, and M. Diane Burton. “Do Startup Employees Earn More in the Long Run?” Organization Science 32, no. 3 (2021): 587-604. https://doi.org/10.1287/orsc.2020.1371

5. Roffey Park Institute. “Assessment and Development Centres Explained.” Roffey Park, 2024. https://www.roffeypark.com/articles/assessment-and-development-centres-explained/

6. Action Learning Associates. “Action Learning Projects.” Action Learning Associates. https://actionlearning.com/solution/action-learning-projects/

7. Organisation Solutions. “Develop Leaders to Deliver Today and Grow for Tomorrow.” Organisation Solutions. https://organisationsolutions.com/develop

About the authors

James Eyring, PhD

James Eyring, PhD is Chief Executive Officer for Organisation Solutions Pte Ltd. He is an Industrial and Organizational Psychologist with over 30 years of experience driving innovation and science-based practice in HR and leadership assessment and development. He is based in New York City and Washington, DC.

Eloi Tay

Eloi Tay leads product, technology, and operations for Organisation Solutions Pte Ltd. He is a computer scientist focused on software development, AI, and automation that help organizations scale growth and operating efficiency. He is based in Singapore.

About Organisation Solutions

Organisation Solutions enables smarter growth and transformation in ambitious businesses. Visit our website to learn more about our assessment, coaching, and leadership development services; explore the Growth Leader Assessment Suite; or join an upcoming LEA.Lab to see a live demo of how AI Agents can partner with talent professionals for Dynamic Succession. Website: organisationsolutions.com‍ ‍