Leadership: Risk or Opportunity Focused

imagesAs I’ve worked with teams engineering teams big and small – in both enterprise and startup contexts – over the last 20 years I’ve noticed two distinct patterns in leadership and their impact on the culture and productivity of those teams.

Pattern: Risk Focused Leadership

Risk focused leadership emphasizes the up front identification and mitigation of risk in any program or project. It attempts to know as much as possible before committing and rewards engineers who can identify and articulate risks.

Impact on Culture

Since the engineer’s perceived worth is derived from her ability to identify reasons things won’t work – or more precisely to avoid mistakes – the culture tends to favor inaction and exhaustive research and analysis.

Impact on Productivity

Predictably, these teams tend to have low output. Generally the output they do generate is both expensive and highly reliable. In enterprise contexts there tends to be a reliance on proven vendors – usually with a bias toward those with long market histories which can be analyzed.

Pattern: Opportunity Focused Leadership

Opportunity focused leadership emphasizes the potential gain of any program or project. It – often aggressively – attempts to capture opportunities as they present themselves. These leaders reward engineers who can grasp the opportunity and rapidly implement solutions which might capture the opportunity.

Impact on Culture

Since the engineer’s perceived worth is derived from her ability to create solutions which may capture the opportunity – or more precisely move quickly with imperfect information – the culture tends to favor rapid cycles of activity and an ability to “change gears” rapidly.

Impact on Productivity

Predictably, these teams tend to have very high output, however, much of that output goes unused. Generally – but not always – the output is proof of concept quality with a bias toward open source tools, frameworks and platforms. Since the long term viability of the opportunity and feature/product were not exhaustively analyzed teams learn to implement low cost solutions which can be “thrown away”.

Leadership Lessons

What should be obvious by now is that neither is bad or good – each is appropriate in certain contexts and, more often than not, a project, program or organization requires a well defined, understood and articulated balance between the two leadership focuses.

Some leaders are naturally opportunistic, some are risk managers. As a leader of a engineering or product development team it is your responsibility to understand:

  • The opportunity/risk profile of the program/project/product.
  • The relative opportunity/risk propensities of your team.

Most importantly, you must ensure that the opportunity/risk profile is articulated and the stakeholders understand and agree with the inherent tradeoffs for any program, project or organization. Failing to do that is the unacceptable risk you must avoid at all costs.

Big Data – Empowering the Age of Agile Analytics

Big data is a buzzword, no question. Given that it is incumbent on practitioners – in particular architects – to tie the new Modern business conceptpatterns available in a “big data” enabled infrastructure to practical business benefits.

While there are a variety of business benefits that are enabled by big data infrastructure the single most tangible is Agile Analytics (also known as self service BI and data discovery and exploration). Here’s why:

1) Your business users never wanted reports.

What they really wanted was to be able to leverage data to answer questions. Traditional BI infrastructure did that well, provided you knew what questions you wanted answered in advance.

The problem is, you don’t. The world moves too fast to create a set of KPIs and instrument your business by those alone for 10 years.

2) Data Driven decision making requires empowered business users.

Business users must be empowered to use the the data directly – without intermediation by technical staff – in order to realize the benefit of data driven decision making.

This isn’t to say the technical staff doesn’t have a role – they do. They provide the platform and advanced support enabling business users to use data directly.

3) The prepared data can only answer known questions.

Business users need to follow the data to the important insights. They have the business knowledge to derive insights that matter, but they can only base those insights in data if they are empowered to explore in the data to follow the information to the value.

This means all the data – from the raw data, through each transformation or aggregation to the KPIs and rolled up analytics.

Big data infrastructure – properly deployed and governed – can provide a platform which solves the key problems preventing business users from engaging directly with the data and discovering valuable insights.

Data Architects – no one cares about your ERD…

Data Architecture has changed – massively – and most data practitioners haven’t caught on yet.

Modern business conceptIn a SaaS world – where business users can sign up for and use powerful platforms by simply signing up we have to radically rethink what data architecture means.

It certainly isn’t about your ERD – your elegant descripton of the data at rest

It is, however, about how that data is acessed, shared, and moves about the technology toplology enabling business agiltiy and experimentation.

So stop using your ERD as a substitute for what a modern data architecture actually requires – a domain model and APIs that enable simple data integration at the point of need.

How to spot a fake Big Data Engineer

9666149041_0a1918019f_o
Photo Credit: counterfitsoner on Flickr

I interview a lot of candidates… I mean a LOT.

And every resume I get these days has a “Big Data Project” listed.

So, naturally, my first question is – what is it that made it a “Big Data” project?

Top five immediate disquallification answers are:

  1. We were using Hadoop
  2. We had TONS of data
  3. We were running map reduce jobs
  4. The data was unstructured
  5. It wasn’t in our data warehouse

The truth is, no one knows what you mean when you say it was a “Big Data” project – and we all know it is on your resume as keyword search fodder – but if you are going to have it on there you better come with a better answer than one of the five above.

Back to Basics

Back to basics

Sometimes, you have to get back to basics. It is too easy to get caught up in the size of the opportunity, an open IPO window or high expectations. 

Great companies are built with an intense focus on customers and problems. Great businesses are built by maintaining an intense focus on the metrics that matter – revenue growth, churn, net promoter, cost of goods sold and customer acquisition costs. 

Great engineering organizations build systems that solve customer problems – without creating new ones.

Great customer success organizations are laser focused on making customers successful.

Great product organizations are obsessed with the market, customers and – ultimately – fall in love with the problem they solve and commit themselves 100% to solving that problem… again, again and again.

When you strip everything else away and get back to basics – prioritize what really matters – you achieve clarity of purpose and message.